翻翻招聘网站、技术大会标题，前几年关键字都是大数据、分布式、千万级用户、亿级PV，今年变成了人工智能、区块链。
热点词汇一两年一换，可换的都是场景，技术还是“旧酒”，一年之间新增的十万级“新XX技术专家”都是怎么来的呢？只不过是新瓶子。
案例一：
最近有人提问：如何构建一个千万用户级的抢购系统？
简答曰：
1.静态文件提前推到CDN，逻辑实现要无状态，可重入/幂等性；
2.库存扣减用内存操作+原子化(比如redis的decr)；
3.前端交互细分步骤，拉长操作时间轴，削平系统峰值压力；
4.用户交互用异步方式处理，包括前端应答和后端处理(MQ)
5.到一定程度时，存入后端，并生成对应单，后续只需通过单ID交互；
追问1：
若单个redis无法承受压力？
回应：
1.多个(Redis)实例，分摊库存量，前端LRU等方式分摊请求压力
2.由于有多个实时变化的库存变量(一个Redis里有一个动态变化的库存变量)，给用户显示的“剩余库存”肯定是不准确的，但这个不会妨碍用户使用(过年上12306的感觉，有谁没怎么体验过吗：D)
追问2：
考虑到全球用户，如果读写的数据不在同一个地方（之间有延迟），该怎么处理
回应：
(What？你这是故意挖坑吧，脑袋正常的人不会允许读写来自有明显延迟的不同地域....但还是继续吧)
1.全局数据带一个时间相关序列ID(时钟问题单独考虑了，不在这其中)
2.写成功后，后端返回一个ID1，本地(浏览器或客户端都行)保存下来
3.发起读请求时，带上ID1，若读取的数据IDn大于ID1则使用；若小于ID1，则取回数据，前端显示时拼接上本地的数据所谓分布式，最难的是处理数据在CAP中的选取。个人倾向的“套路”如上描述，
1.细分步骤以削峰；
2.插入中间保存数据的环节，减少某一步骤失败带来的体验损失 or 用户流失；
3.在CAP中选择一个可以“牺牲(稍后完成)”的
to be continue...