高并发和高可用在电商系统中的实践经验分享

先说一点，最近有人私信我：“有工作，没人带，怎么办？”

哎，这个问题真是个好问题啊。我只能告诉你一点，学习这件事只能靠自己，别人谁都靠不了。如果没人带，那就多看我的微信公众号里的文章。里面有很多的学习教程和视频资源，都可以免费获取。如果有技术的问题，可以加我好友，我们在微信群里，共同学习，共同进步！

高并发和高可用一听就好像挺牛逼的啊，高级工程师和架构师才摸得到吧。但其实呢？这个东西并不难，理解起来很简单，难在于实践！

先不谈传统的5大IO模型，先说说"并发（Concurrence）"。一个非常不严谨的解释就是同时做A和B两件事。先做一会儿进程A，然后上下文切换，再做一会儿B。过一会儿在切回来继续做A。因此给我们造成一个假象，我们同时在做A和B两件事。这就是著名的进程模型。

在说说并发的本质、并发的核心就是如何在代码中协调好并行处理和串行处理！各种并发技术，其实质都是在并行和串行之间转换，追求性能最大化，又要守住结果正确性这条红线！就像高速公路，有些路段你可以飙车，但是到了收费站，你必须慢下来，一个接一个通过检查。并发中的锁，必须是唯一的锁，不然就会失去唯一性访问控制，锁的唯一作用就是排他的访问控制。

如果仅是追求高可用性，这其实并不难做，试想如果一年只有一个人访问你的系统，只要这一个人访问成功，那你系统的‘’可用性‘就是100%了。可现实是，随着业务的发展，请求量会越来越高，进而各种系统资源得以激活，那潜在风险也会慢慢的暴露出来。因此，做系统的难点之一便是：如何在高并发的条件下，保证系统的高可用。

明白了这个东西后，我们再来看看我们电商系统中的相关使用技巧。

高并发设计原则：

• 无状态设计：因为有状态可能涉及锁操作，锁又可能导致并发的串行化。
• 保持合理的粒度：无论拆分还是服务化，其实就是服务粒度控制，控制粒度为了分散请求提高并发，或为了从管理等角度提高可操性。
• 缓存、队列、并发等技巧在高并发设计上可供参考，但需依场景使用。

高可用设计原则：

• 系统的任何发布必须具有可回滚能力。
• 系统任何外部依赖必须准确衡量是否可降级，是否可无损降级，并提供降级开关。
• 系统对外暴露的接口必须配置好限流，限流值必须尽量准确可靠。

业务设计原则：

• 安全性：防抓取，防刷单、防表单重复提交，等等等等。
• at least 消费，应考虑是否采用幂等设计
• 业务流程动态化，业务规则动态化
• 系统 owner 负责制、人员备份制、值班制
• 系统文档化
• 后台操作可追溯

现在技巧（原则）是有了，但是光讲道理有毛用啊。道理谁都会讲啊，我要的是实战。

实战，那好，我们就拿现实生活中的超时来说，不管你选购什么东西，最终都是排队结算。收银员就是我们的服务，每一个在队列中的顾客都是一个请求。我们的本质诉求是让尽可能多的人都在合理的等待时间内完成消费。如何做到这一点呢？其一是提高收银员的处理速度，他们处理的越快，单位时间内就能服务更多的顾客；其二是增加人手，一名收银员处理不过来，我们就雇十名收银员，十名不够我们就雇佣一百名（如果不计成本）；其三是减少访问人数，也即分流过滤，将一些人提前过滤掉，比如，没有购物的人请未购物通道等。

因此，想要高并发无外乎从以下几个方面入手：

• 提高处理速度：缓存、异步
• 增加处理人手：多线程（多进程）、扩容
• 减少访问人数：预处理（比如小米手机先预约再抢购）

但是现在扯到缓存了，掉陷阱里了。缓存的东西可以给你扯好几本书。比如，前端缓存，数据缓存，图片等文件缓存。缓存命中率、缓存穿透、回收策略、null穿透问题、惊群问题、缓存热点问题、缓存一致性问题、读写扩散问、读更新、写更新、异步更新、java堆内缓存、java堆外缓存、磁盘缓存、分布式缓存，多级缓存。。。

扯到异步，就有异步编排。操作系统层面，IO层面，延迟处理，缓冲队列，任务队列，消息队列。。。

到最后，你会发现，所谓的高并发技巧，其实就是多“维”优化。

好的架构不是设计出来的，而是优化出来的。

马丁·福勒（Martin Fowler）的相关书籍，建议大家可以多看看。最后，希望大家关注我的微信公众号，https://mp.weixin.qq.com/s/GdI03ERiz3pwAydj1NyhSQ 这些问题，我们一起来解决！

： » 高并发和高可用在电商系统中的实践经验分享