高并发系统项目开发实战经验

最近参与实现了一个CCU预计240w+ 项目，学习了各位大佬们的思路和代码。记录分享一下一些拙见。

1. 一般的架构瓶颈首先出现的都是存储瓶颈
2. redis官方给出的单key的最高qps大概是10w/s，自己测了一下多个命令get、set、zadd等等都能达到10w/s(本机)
3. 用redis存储的话，几乎就能支持接近10wqps量级的流量。（单机）
4. 但也带来的持久化的问题，自己的想法(口嗨)：
   ----------a 在写redis的同时，发送kafka消息，消费者去持久化数据。
   ----------b 定时任务以不高的频率(尽量不影响业务)去从redis中拉取信息持久化
   —不管怎样还是以redis为第一准确数据
5. 在设计数据结构、业务逻辑的时候遵循原则：能够只访问一次redis就不访问两次。尽可能的降低redis的压力
6. 设计多级缓存： 内存+redis。 在一些业务逻辑上(比如库存)，完全可以从redis中先拿一部分指标放入内存使用。 比如拿10、100个放入内存，用不完就扔掉允许误差(如果不允许可以定时维护)，支持能力会成数量级增长。或者初始化的时候一次性全放进内存
7. redis-key 分桶。单key在redis集群中必然存在一个机器上。如果这个key成为热点key，那它能支持的qps有上限，而且很可能出现那台机器上因为这个key的qps过高 拉满cpu而导致服务不可用。一个key分成100个key，再定义一个简单的散列函数，那么如果每个key都能支持10w的qps，总共就能支持1000w量级（分布在多台机器上 ，理论上）。
8. 在一些可以静态刷新的页面上，就静态刷新，把redis压力分摊一部分到其他机器上(比如cdn)。
9. 设置限流器、计