活跃用户处理机制 将过载保护设置在CGI入口层
随心所欲
当我们的用户量逐步上升，系统依然出现吃紧和性能跟不上的阶段。
这个时候，我们大量使用一致性Hash和随机算法，其中过程就变成了。
将秒杀的产品ID分成多个队列放在Redis集群上，然后将一个产品总数量放在一个Redis上（这个Redis是瓶颈，但是基本上20W的TPS满满的达到了）
为用户随机一个数字，在一定范围内，直接告诉秒杀失败（纯看运气，纯丢给应用服务器去玩了）
检查用户规则和用户积分，还有产品总数量，总数量为0，直接结束。
为用户随机一个产品ID队列，尝试pop，pop不出数据，直接结束（还是看运气）
更新用户Redis的缓存和产品总数量的缓存（decr），然后交给RabbitMQ和消费者慢慢处理。
这个时候，基本上30wTPS，随便玩。
返璞归真
说了这么多废话，总结下吧。对于秒杀这种业务，优先保稳定和正确，最后才能保服务量。不稳定没得玩，不正确，很可能一单亏死。技术上，我个人认为小厂也能做看似很NB的秒杀只要用好以下几个相关技术：
削峰，不管是随机丢弃，还是多层筛选，尽可能减少进入核心业务的用户数
排队，在秒杀场景下，排队不单单可以减少系统压力，还能保证正确性
分区，使用分区可以降低一个节点当机带来整体性的损害或者雪崩性的系统不可用
最终一致，很多时候，不一定要强一致性，只要能保证最后数据的正确，哪怕是手工修复，都能带来大规模的性能提升
