朴素系统优化思维的实践
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了朴素系统优化思维的实践相关的知识，希望对你有一定的参考价值。
作者：京东物流 严孝男
一、问题
去年年中时候，我有个好朋友（可以叫他华哥）顶着当时还很严重的疫情形式激情创业，斥巨资承包了他原公司食堂的几个摊位，摇身一变成了老板。当了老板的华哥没有丝毫懈怠，不但做了充足的市场调研，还结合他自己以前就餐时的痛点做了创新，比如以前食堂除了最常规的面，饺子，米线一类的之外就是一份份的卖炒菜，差不多一份荤菜十几块，一份素菜近十块的样子，这就导致一个问题，一般男生花了几十块钱也就只能吃到2-3个菜，不但营养不够丰富，万一踩坑遇到了原本抱有很高期待但发现实际菜并不好吃的情况，体验就更差了。
所以华哥借鉴了市面上麻辣烫自选称重模式的特点推出了自助选菜称重的模式，餐台上会摆放很多种做好的菜（荤素凉都有），大家根据自己的喜好自己打菜，主食的米饭和馒头免费，粥和汤也免费，然后还提供一些收费的主食比如红薯，玉米一类的，打菜的流程就是大家从台子两边按顺序开始自选打菜，然后选择主食，然后选择汤粥，然后结账刷卡，如下图所示：
华哥不愧是前互联网大厂的金牌产品经理，其敏锐的抓住了用户的痛点，并很好的给出了相应的解决方案，自助称重模式自从推出后就受到了同事们的热烈欢迎，每次都排了长长的队伍，甚至中午11点半开餐，不到11点20就有很多同事在排队等着，写到这里我想举个排长队的例子给大家一个直观的印象，我最开始想到的例子是五道口那个枣糕店门口排的长队，后来一想现在京东2号楼B座4楼餐厅里排瓦罐的队伍好像更贴切。
华哥开始的时候非常开心，但一个月后做了营收盘点发现有点不对，虽然看上去队伍排得很长很火爆的样子，但实际上营收并不如预期。华哥分析了一下排除了客单价低的因素，自选模式下好多菜大家看到后都想来一点，一来二去就会打好大一盘，基本都是20元起步的客单价；然后就剩下单量低这个可能性了，实际分析一下就可以发现，因为菜的可选品种很多，所以选菜环节每个人需要花很长的时间选菜，再加上需要打汤和打饭，一个人实际完成整个取餐的过程耗时是很长的，虽然后面的同事可以跟在前面同事后面串行打菜，但因为每个人的喜好不一样，所以每个人在不同菜前的停留时间不一样，这就导致当前面的同事在某个菜盘前耗时稍长的时候，后面的同事是处于等待状态的。
而且有的时候还会遇到一些极端的情况，比如有些同事会在某些他爱吃的菜前停留很久挑挑拣拣，还有些同事会在打免费汤时拿着大勺顺逆时针交替着疯狂搅动，以此企图捞起汤里那些零散的沉底的菜叶和鸡蛋白，华哥就亲眼目睹了他以前汇报的经理在辣子鸡丁菜盆里翻来覆去的寻找隐匿在辣椒深处的那一点点鸡肉，每发现一块鸡肉时经理的脸上还会露出那种心满意足充满成就感的笑容，话说回来其实在经理挑鸡肉时整个队伍实际是处于完全停滞状态的，所以综合来看整个队伍的执行就餐过程是非常缓慢的，也就导致实际打完餐付费的人数并不如想象中多。
二、方案
后来在一次好友聚会时，华哥和我聊起了这个事情，他问我：你们搞技术的不都各种吹嘘什么系统优化，降本增效一类的吗，你帮我想想办法。听完华哥这略带挑衅意味的要求，我突然觉得自己身上有了很重的责任感，觉得自己要守住技术人的尊严。于是自己好好想了想，然后觉得这个商业问题实际上也可以看成一个技术问题，这个餐台可以看成一个系统，打餐的流程可以认为是系统的一次交互流程，每个打菜的同事可以看成是一次调用，因为每次调用执行起来的性能太差，导致系统整体的吞吐量太低，影响了整体系统的效能，因此整个系统的效能很低，虽然当时已经是酒过三巡，脑子不太清醒了，但是自己还是尽力给华哥想了好几个办法。
2.1 系统扩容
第一个想到的办法就是扩容，在工程技术领域当遇到系统性能不达标时，第一个想到的解决方案也一般都是扩容，工程领域里的扩容一般可以分垂直扩容和水平扩容两种方式：垂直扩容是通过提升单体实例的硬件能力来提升单体处理能力，水平扩容则是通过增加实例节点的方式来增加整个系统的处理能力。
套用这两个理论，看看怎么提升餐台的吞吐，好像垂直扩容这块能做的不多，总不能把打饭的勺子升级一下变成德国原装进口高温武火蹴练镀金勺吧；不过虽然垂直扩容没什么好办法， 但是水平扩容好像能做的事情很多了，只要多增加几套打菜餐台，这样并行执行的2条打饭队伍就可以变成4条，甚至8条，直接实现了多线程并发，这样系统整体的吞吐能力可以立马获得翻倍式提升，效果不但见效块，效果也可谓是立竿见影，于是我给画了一个水平扩容示意图，如下图所示：
不过水平扩容的方案很快就被华哥否了，虽然在工程技术领域，随着云原生技术的成熟，应用级别的扩容缩容都是很成熟的提升系统处理能力的解决方案了，但是在华哥这里，想再搭一个餐台是不可能的，且不说华哥承包的摊位没有这么大的地方去搞第二个餐台，就算有，从新施工装修，水电改造一系列的成本也几乎是不可能实现的。
虽然这个世界上能用钱解决的问题都不叫问题，但现在的问题是华哥没钱了。
2.2 单次执行优化
提升系统并发能力的路走不通后，那么提升系统的吞吐量的办法就是缩短单条请求的处理执行时间，这样单位时间内系统处理的请求条数就会有提升，从而提升系统吞吐量，那回到餐台这里，就变成了需要缩短单人打餐的时间，尤其是遇到华哥前经理那种在单个菜盘前会耗费大量时间的情况该如何优化呢？
我们拆分一下每次调用，把在每个菜盘前打菜的过程可以模拟理解为执行一段逻辑，这样全部的打菜过程可以被拆解成一个个小的代码块，总的调用时间是由这些代码块的执行时间之和决定的，从工程技术视角的话就是保证每段逻辑都在一个可预期的时间内完成，所以每段逻辑都可以通过一个超时判断逻辑来控制每段代码的执行时间，这里举一个百度搜索的例子，百度为了增强返回结果的多样性，推出了阿拉丁架构，每个query经过星图模型解析后会分发给不同的垂类，每个垂类会加工生产属于自己业务领域的卡片，然后阿拉丁的root应用聚合垂类返回的各个结果并返回给用户，那某些垂类场景执行会比较慢，比如当遇到用户搜一款药的场景时，健康垂类的应用会根据搜索人的经纬度筛选附近的o2o的药店，并计算该药品在该门店的促销折扣价，这种计算往往会耗时很久，所以root应用会增加一个380ms的超时判断，对所有的垂类应用都是一样，当你返回的内容超过这个时间后结果会被丢弃，举这个例子让大家可以明白通过增加对每个环节的超时设置，这样可以保证整体的流程在一个可控的时间范围内得到执行，从而保证用户体验的一致性。
程序里的超时好加，因为程序没有喜怒哀乐，但打餐的场景不一样，总不能在每个菜后面安排一个服务员在背后数123计时，超过5s往前推他一把，总不能这样吧，究其原因就是打菜是主观能动的，他想在一个菜前停多久就停多久，想到这个问题后，我有了主意，把用户自主停留的权利给剥夺，创造统一的停留时间，所以我给华哥设计了一套超时装置，那就是在餐台的两边各增加一套自动传送装置，类似于飞机场里安检后赶去航站楼的传送带一样，这样人们在两边打菜时不需要自己走动了，而且每个人在每个菜盘前停留时间是一样的，就不会出现一个人在某个菜前停留时间过久的问题，也避免了餐台因前面某个人的长时间停留而出现整体停滞的问题，提升了餐台的吞吐量，而且传送带的增加还有个好处就是人不多时可以开得很慢甚至停掉，在高峰期时可以适当增加传送带的速度，从而控制每一个人打菜的时间，保障整个餐台的吞吐率。
华哥听到我这个有点天才的想法后愣了很久，盘算了一下可能性后他觉得这个办法还真的可行，只是需要等到十一或者五一长假期间动工在两边增加传送带，终于听到一个可行方案的华哥有点兴奋，两腮也泛出了点点的红晕。
2.3 非核心流程剔除
看到华哥接纳了我的这个方案，我顿时感受到了很大的鼓励，于是又继续思考这块流程还能怎么优化，在工程技术领域，一个流程在承受很大流量时还可以做的一个事情就是流程简化，只保留核心的流程环节，也就是大家常说的黄金流程，而将非核心的业务节点从主流程中剔除，这样精简后的主流程可以一定程度上缩短执行时间，而且主流程执行的逻辑少了，出错的概率也同时就降低了，举一个京东零售的下单计算流程为例，零售侧结算时需要做以下的事情：
实际上结算这块还有很多的非主要节点要处理，比如删除购物车中相关已结算商品，预占自提柜等等，但是这些属于非核心的流程，可以从主流程中剔掉。
回到餐台这里，什么流程是黄金流程，没错，就是那些和营收直接相关的流程，而那些不产生收益的项目，比如米饭馒头，汤粥的环节就可以认为是非主要流程，可以从主流程中剔掉，这样不断简化了大家取餐的主流程，而且还节省了餐厅的空间，剩余的空间可以用来做几件事，一个是可以多放一些收费的主食或者增加一些菜品，以此可以增加收入，第二个可以增加一些自助收银设备，之前2个收银台在之前打餐比较慢时可以满足需求，但现在整个流程简化了，整体每个人的打餐速度提升了，这样2个收银台就会变成新的瓶颈，尤其是遇到有扫码直付的同学就会瓶颈的更明显，这样通过增加收银台的数量，从而提升了收银环节的并发处理能力，保证了整个取餐流程的流畅，避免新的性能瓶颈的出现，完美！
华哥听完这个建议很满意，他正嫌餐台太小摆放的菜系不够多呢，这样空间被更合理的利用到能带来收益的食品上了，正合华哥之意，华哥很开心的敬了我一个。
2.4 分布式缓存
除此之外，互联网增加系统吞吐能力，缩短单次执行时间的一个很主要的法宝利器就是利用分布式缓存技术，分布式缓存技术可以让很多存在系统瓶颈的调用通过缩短数据获取时间从而极大缩短处理时间，在这里分布式缓存技术是不是也可以利用到餐台这里呢。
我想了一下，前面从主流程中拿掉的免费主食部分和汤粥部分可以利用缓存的原理，尤其是CDN缓存的原理，把主食和汤粥分布式的放在离同事们就餐的餐桌附近，这样可以让就餐的同事们最近范围就可以盛到主食和汤粥，表面上看对营收没提升，但实际上一是大家打饭近了，就餐体验好了，二是大家打饭加饭方便了，就餐的时间就会降低，从而提升餐桌的利用率。保证下一个打到饭的同事能快速找到座位，体验同样也会提升。这里我就不画图了，相信大家都能明白。
三、后记
华哥整体听完我的优化方案后低头陷入了沉思，许久之后他抬起头看着我，眼神有些许迷离，我顿时有点紧张，以为他要系统点评一下我的方案，没想到华哥开口问我的是，现在几点了，我才意识到华哥刚才是喝多了低头睡着了。
性能优化：关于缓存的一些思考
作者 | 烛衡
利用缓存做性能优化的案例非常多，从基础的操作系统到数据库、分布式缓存、本地缓存等。它们表现形式各异，却有着共同的朴素的本质：弥补CPU的高算力和IO的慢读写之间巨大的鸿沟。
和架构选型类似，每引入一个组件，都会导致复杂度的上升。以缓存为例，它带来性能提升的同时，也带来一些问题，需要开发者设计和权衡。
本文的思维脉络如下：
一 缓存和多级缓存
1 缓存的引入
在初期业务量小的时候，数据库能承担读写压力，应用可以直接和DB交互，架构简单且强壮。
经过一段时间发展后，业务量迎来了大规模增长，此时DB查询压力和耗时都在增长。此时引入分布式缓存，在减少DB压力的同时，还提供了更高的QPS。
再往后发展，分布式缓存也成为了瓶颈，高频的QPS是一笔负担;另外缓存驱逐以及网络抖动会影响系统的稳定性，此时引入本地缓存，可以减轻分布式缓存的压力，并减少网络以及序列化开销。
2 读写的性能提升
缓存通过减少IO操作来获得读写的性能提升。有一个表格，可以看见磁盘、网络的IO操作耗时，远高于内存存取。
-
读优化：当请求命中缓存后，可直接返回，从而略过IO读取，减小读的成本。
-
写优化：将写操作在缓冲中合并，让IO设备可以批量处理，减小写的成本。
3 缓存 Miss
4 缓存一致性
-
延迟双删：主线程失效缓存后，将失效指令放入延时队列，另一个线程轮询队列获取指令并执行。
-
CDC同步：通过canal订阅MySQL binlog的变更，上报给Kafka，系统监听Kafka消息触发缓存失效。
二 从堆内存到直接内存
1 直接内存的引入
2 直接内存管理
三 CPU 缓存
1 CPU cache line
2 伪共享 false sharing
NoPadding {
long no0;
long no1;
}
3 伪共享解决方案
Padding {
long p1, p2, p3, p4, p5, p6, p7;
volatile long no0 = 0L;
long p9, p10, p11, p12, p13, p14;
volatile long no1 = 0L;
}
@sun.misc.Contended static final class CounterCell {
volatile long value;
CounterCell(long x) { value = x; }
}
四 总结
以上是关于朴素系统优化思维的实践的主要内容，如果未能解决你的问题，请参考以下文章