秒杀系统架构思路

应用场景

限时抢购，10w人抢购100个商品。这种情况下如果直接走到数据存储层，瞬间会把数据库打挂掉，如果业务处理不好（流程过长），会出现超卖现象

优化方向

尽量将请求拦截在上游

充分利用缓存
1. 前端方案
- 页面静态
- 防重复提交
- 用户限流
2. 后端方案
- 网关限制
- 缓存
- 消息队列削峰

优化细节

这里我们由简单往细节深入（因为要考虑实际的用户量，先做最简单最有效的处理）

简单高效处理方式

1. 前端防重复提交
   这是最基本的
2. redis缓存校验
   如果没有缓存，由于业务校验时间过长，比如在200ms内10w个人同时读了数据库库存仅剩1，都是可购买的，然后同时走到下单流程就会超卖，另外就是如果并发量过高，数据库会挂掉。
   如果是缓存校验，则只有一个可下单。其余全部直接拦截。

redis数据类型选型
如果不考虑抢购的下单数量和购买限制大于1，那直接kv或者list都是可以的。否则可以考虑hash或者zset。

这里对比一下kv和list：
kv的一般处理方式是预加或者预减：累计购买数量超过总库存或者剩余库存小于0，则校验不通过，同时回退。
list：预存库存长度的list，不断pop，无法pop则校验不通过。

tip：注意原子性
判断最好走lua。
比如kv，如果库存1，10人同时下单，如果是程序判断，则全部不能下单。而如果用lua，用户判断和回退是原子性的，则有一个人可以下单成功。
如果使用list，当抢购数量大于1时，回退也需要用事务，不然会出现，比如库存3，A下单5，B下单2。B在回退push的过程中，又被Apop了1从而判断库存不足。导致两人都不能下单。

复杂完善处理方式

1. redis集群，主从同步，读写分离（读多写少）。
2. nginx负载均衡
3. 前端资源静态化：只有少部分内容是动态的的
4. 按钮控制
5. 缓存预热
6. mq削峰：队列下单

详细内容可以参考大佬们的文章，我只是一个搬运工

架构设计图：

参考文档：
https://www.zhihu.com/question/54895548
https://yq.aliyun.com/articles/69704?utm_campaign=wenzhang&utm_medium=article&utm_source=QQ-qun&utm_content=m_10737

一、应用场景

1. 对于商城系统而言，定时任务会非常多，比如优惠券过期、订单定时关闭、2小时订单未支付自动取消等等。常用做法是写数据库指定过期时间，定时循环读表，当数据量一大，这种会严重影响性能，产生巨大的io。
2. 而另外一些基于redis实现的延迟队列，也是基于pull拉模式去实现的，也会产生io，只是变成了内存读取。
3. 一种好的做法是 push 推模式，服务端主动推送，这里就是rabbitmq的死信队列去实现

二、延迟队列原理

延迟队列一般分为两种:
- 基于消息的延迟和基于队列的延迟。基于消息的延迟是指为每条消息设置不同的延迟时间，那么每当队列中有新消息进入的时候就会重新根据延迟时间排序，当然这也会对性能造成极大的影响。
- 实际应用中大多采用基于队列的延迟，设置不同延迟级别的队列，比如 5s、10s、30s、1min、5mins、10mins 等，每个队列中消息的延迟时间都是相同的，这样免去了延迟排序所要承受的性能之苦，通过一定的扫描策略（比如定时）即可投递超时的消息。
- 这里主要通过rabbitmq的死信队列实现，需要同时声明一个缓冲队列和一个延迟队列，给缓冲队列设置统一消息过期时间，当消息过期后，会自动被重新投递到死信队列（死信队列也是一个普通队列），只需要监听死信队列即可

三、api项目使用说明

1. 首先需要定义延迟消费队列：即不管是订单关闭，还是优惠券过期的后续处理，都需要去监听这个消息
   在  application/libraries/mq/MqDlxQueue 去定义
   
2. 运行声明脚本
   php mq/StartDlx.php DELAY_QUEUE_TEST
3. 定义缓冲区队列：即所有投递到这个队列的消息，设置统一的过期时间，比如固定2小时关闭订单，可以设置统一的队列过期时间为2小时。

   这里需要指定 dlx_key：即过期后投递到的死信队列的路由
   需要指定 message_ttl：即统一的消息过期时间，单位 毫秒

   注意：该 缓冲队列的 key，不要有任何消费者，不然被其他消费者消费后，就不会过期

   在 application/libraries/mq/MqQueue 去定义
   

4. 声明 缓冲队列
   php mq/Start.php BUFFER_QUEUE_TEST
5. 设置 延迟队列消费者 
   
6. 发送 消息到 缓冲区
   

7. 测试效果：
   

   

如何避免key冲突？

• select db
  • 默认db16个，编号0~15，可通过配置修改db个数
  • 默认使用db-0
• key命名格式
  • 以"xxx:yyy:zzz"格式命名

安全考虑

• 访问限制
  • 只对内网访问，以防外部通过6379端口访问
• 危险函数
  • 禁用危险函数：flush、flushall
• 使用秘钥
  • $redis->auth(password)

性能提升

• 连接
  • 使用官方扩展，弃用predis
  • 使用单例方式连接，使用pconnect
  • 用中间件，实现连接池
• 持久化策略
  • 根据实际情况，关闭持久化
• 服务部署
  • 与web服务共存，本地调用
  • 与存储服务隔离（mysql），避免高io
  • 一主多从，提升性能，或使用集群
• 版本升级
  • 低版本：setnx + expire
  • 高版本：set(k, v, array(ex, nx))
• 批量操作
  • 使用管道命令，批量导入数据
  • 使用mset, mget
• 合理操作
  • 使用hset存放json，而不是set
  • 使用scan代替keys
  • Nginx + Lua + Redis

问题：
如何检查redis服务是否健康？

高性能

• 简洁的通讯协议，快速连接
• 操作基于内存，快速读写
• 成熟的数据结构，快速定位
• 基于牛X的语言实现，快速运行
• 主从架构，读写分离

高可用

• 异常监控，自动化应急
• 数据灾备，快速恢复
• 主从架构，从服务上位
• 分布式、集群化
• 服务自动降级
• 多级缓存

存储

• 成熟的数据结构，减少冗余
• 数据压缩方案，减小数据大小
• 置换算法：FIFO、LRU、LFU
• 索引，以空间换时间
• 数据分片，快捷扩容、无限扩容
• 一定要设置过期时间！

常见缓存过期策略

策略	优点	缺点
定时过期： 每个设置了过期时间的key，都携带一个定时器做倒计时，到期自动删除	立即清除，无空间浪费	定时器占用大量cpu，影响性能
惰性过期： 只有当访问的时候，才会判断是否过期，过期则删除	最大化节省cpu	过期数据未被访问时，会占用存储，造成空间浪费
定期过期： 每隔一定时间，随机扫描一定数量带有有效期的key，并清除其中已过期的key	前两种的这种方案	难点： 需要合理设置 “时间”、 “数量”

常见存储置换策略：FIFO、LRU、LFU

• FIFO（first in first out）
  • 淘汰最早的数据
• LRU（least recently used）
  • 淘汰最长时间未被使用的数据
• LFU（least frequently used）
  • 淘汰使用次数最少的数据

Redis置换策略配置（maxmemory-policy）

• noeviction：不置换
• volatile-[ lru | random | ttl ]
  • 对具备有效期的key，按lru/随机/最短置换
• allkeys-[ lru | random ]
  • 对所有key，按lru/随机置换

一致性

缓存与数据库保持一致
- 低效做法：使用事务，数据库与缓存的更新
- 符合ACID
- 业务普遍做法：先更新数据库，再删除缓存
- 严谨但复杂的做法：消息队列、订阅binlog

旁路缓存原则：

读操作：
- 先读缓存
- 如果命中，直接返回
- 如果未命中，访问DB，并写入缓存

写操作：
- 删缓存，而不是更新缓存
- 先写DB，再删缓存

问题：
以下方式，存在什么隐患？
- 先更新缓存，再更新数据库
- 先删除缓存，再更新数据库
- 先更新数据库，再更新缓存

防雪崩

高并发时失效
雪崩：在用户高并发瞬间，如果缓存不可用（失效），用户的请求压力，都转到数据库，导致数据库挂掉，并最终导致整个系统挂掉。

如何防止缓存雪崩的发生？

• 缓存服务高可用
  • 服务挂了，做什么都没用
• 多个缓存不能同时过期
  • 随机失效，而不是同时或定点
• 多级缓存
  • 多级缓存，尽可能把数据库挡在后面
• 使用互斥锁
  • 只有拿到锁的请求，才能查库
• 排队限流
  • 控制查库的并发峰值
• 提前预热
  • 预先更新缓存
• 公用性质缓存更应重视
  • 如：首页、推荐位
  • 个性化数据相对风险小

// 业务中改成这样是否有问题
function getDataBuyKey($strKey) {
    // 从缓存中取数据
    $arrData = getCacheData($strKey);
    // 如果未命中缓存，或缓存即将失效，抢占锁
    if (!$arrData || $arrData['ttl'] - time() < 10) {
        // 如果抢锁成功（带有效期的锁），可以查库
        if (redis::set('lock_' . $strKey, 1, array('nx', 'ex' => 10))) {
            $arrData = getDbData($strKey); // 查库
            setCacheData($arrData); // 更新缓存
        }
    }
    return $arrData;
}

防穿透

被故意不命中
用户伪造大量请求，故意不命中缓存，当这些请求集中转到数据库时，导致数据库挂掉，并最终导致整个系统挂掉。

如何防止缓存穿透的发生？

• 缓存空值
  • 额外缓存一份空值，以防反复查库
• 缓存数据范围
  • 如，应用ID范围、页码范围、时间段
• 预先使用布隆过滤（bloom filter）
  • 一定不存在的数据，请求将被拦截

function getDataBuyKey($strKey) {
    $arrData = [];
    // 先执行key的有效验证
    if (checkKey($strKey)) {
        // 从缓存中取数据，未取到，返回null
        $arrData = getCacheData($strKey);
    }
    // 如果未命中缓存，或者缓存即将失效，抢占锁
    if (is_null($arrData) || $arrData['ttl'] - time() < 10) {
        // 如果抢锁成功（带有效期的锁），可以查库
        if (redis::set('lock_' . $strKey, 1, array('nx', 'ex' => 10))) {
            $arrData = (array)getDbData($strKey); // 查库
            setCacheData($arrData); // 更新缓存，若为空值，写入"[]"
        }
        is_null($arrData) && $arrData = []
    }
    return $arrData; // 返回空数据，或即将失效的数据，或最新的数据
}