软件架构阅读笔记11
应对突发的峰值访问，高压下的架构演进（数据）
京东商城数据流向：
- 订单生成前，包括单品页，购物车，架构，促销等功能，我们每个用户进来需要访问。它的特点是大促期间访问量非常大
- 订单预处理，订单生成之后，这是一个原始生成单，之后需要对订单进行预处理，进行拆包，包裹的拆分、大家电小家电拆开包裹运送等。因为是统一下单，这一块是订单预处理。挑战是访问量大，各个模块如拆单、订单转移，支付台帐等可能会承受非常大的压力，我们会采取扩容存储，限流，数据结构优化等方法去应对。
- 订单履约阶段，真正到后面是整个处理过程，配送黏合起来做的系统。这是京东商城的服务结构。
交易系统的三层结构
上面是调用来源，中间是我们的服务，下面是依赖的底层服务。其中强依赖服务是关键路径所需要调用的服务，是主流程中不可缺少的一部分。
强依赖服务在大促期间不能被降级，我们需要提前扩容，以及进行代码重构、拆分、按来源单独部署等方法提前进行优化。
交易系统的访问特征
购物车：结算页：产生订单页面访问的比例是 16 ：4 ：1。每天 PV 就是几十亿，几百亿、上千亿，因此我看到最大的量 1 分钟是几千万。
全链路全流量线上压测
系统会有很多的变更，数据变更或者是代码变更结构变更都会产生，我们知道这个系统能够承受多大量，上来对它进行压测。
压测分为线上压测、线下压测，主力做线上压测。（下压测，环境跟线上不一样，路由器和机器 CPU，物理机，每一个不相同或者架设的路由超过 3 层，丢包，各种数据不一样，压测出来的数据经常会差异。）
压测方法：
- 演练缩减服务器：把集群机器逐台往下缩减，真正看到线上量能扛到什么情况。
- 复制流量：主要通过 TCPCopy 复制端口流量，多层翻倍放大流量。
- 模拟流量：非常简单的底层工具去做压测。用压测平台，把这些工具集成起来做模拟流量压测。
- 流量泄洪：把订单在这个结构，接住堵在这个地方不往下放，往后拽都是密集的一些服务。从这一块把量堵住，堵几十万，突然有一天打开，看到一个峰值，看每一分钟处理量，往后能承受多大量，是不是能够承受发起的量。
根据压力表现进行调优：
- 多级缓存：逐级做缓存，前面做一些静态缓存掉，后面会做一些基础数据缓存，最后大数据，一层一层往上能挡住整个这一块，
- 善用异步：异步双写，会写丢数据，写丢没关系，购物车是整体的，加一个商品，写不过来，下次过来又会全覆盖。这样购物车就有一个多机房多活的可用性。
- 超热数据的缓存：利用 Queue 的原理，不断往里塞 SKU
- 数据压缩：对 Redis 存储的数据进行压缩，这样空间又缩小四分之一或是三分之一，数据到后面就会很小。当量小之后，访问效率就会升高，数据量弹出很小，丢单率很小，可以提高可用性。
