高并发读，高并发写解决方案

高并发读

• 动静分离与CDN加速

  网站开发分为静态内容和动态内容两部分。
  1. 静态内容：常用的处理测了就是CDN，一个静态文件缓存到网络各个节点。

• 加缓存

1. 当数据库支持不住时，首先想到的是加一层缓存，一种是本地缓存，另一种是集中式缓存，比如redis
2. 缓存的数据结构通常是结构，v是普通对象也有复杂一点的 结构
3. 缓存的更新有两种，一种是主动更新，当数据库数据发生变更时，主动的更新缓存中的数据，另一种是被动更新，当用户的查询请求过来时，如果缓存过期，则在更新缓存。
4. 基于master/slave。比如后端复杂业务的操作，直接查询数据库，影响c端用户。可以基于mysql加一个换多个slave来分担主库的读压力。
5. 基于表的缓存，把多张关联表查询结果缓存成数据。任何一个表内容发生了更新，缓存都会更新，

• 并发读与Pipeline

6. 异步RPC
7. Pipeline操作，对于缓存或存储，单个的set/get之所以慢还有一个原因是，通常都是异步接口,上一个Get操作发出去之后，需要等待返回结果，才能发出下一个Key，如果采用Pipeline方式多个Get操作一个个发出去，不等返回结果，就像流入一个管道一样，结果从另一个管道渊源不断的流出。实际上也是读写的异步化

• 批量读

1. 缓存或存储中的批读/批写接口，一次传多个key进去，相比单个Get/set操作，少了网络传输次数，但是也不能传太多的key，否则超过以太网MTU大小，在底层网络页面还是要多次传输。
2. mysql的select/insert，一次查询多条或插入多条

• 重写轻读

3. 宽表操作：提前把关联数据计算好，保存在一个地方，读的时候直接去读取聚合好的数据。

• 总结（读写分离）

无论加缓存、动静分离还是重写轻读，其本质上都是读写分离。

1. 分别为读和写设计不同的数据结构，在C端同时面临读和写的高并发压力时，把系统分成读和写两个视角来设计，各自设计适合读和写的数据结构或数据模型
2. 写的一端，通常也就是在线的业务数据库，通过分库分表抵抗写的压力。读的一段为了抵抗高并发压力，针对业务场景可能是缓存，也可能是提前做好的宽表。
3. 读与写的串联，定时任务定期把业务数据从数据库中转换成适合高并发读的数据结构，或者是写的一端吧数据变更，推送到消息中间件，然后读的一端进行消费。在或者直接监听数据库的binlog
4. 读比写有延迟，因为写的数据实时变化，读的数据肯定有延迟，读与写之间是最终一致性，而不是强一致性，但这并不影响业务的正常运行。

高并发写

• 数据分片

就是对处理的数据或请求分成多份然后并行处理。

1. 数据库的分库分表；数据库为了应对高并发读的压力，可以加缓存，slave；为了应对高并发写的压力，就需要分库分表了，分表后，数据还在一个数据库，一台机器上，但可以充分利用cpu、内存，分库后可以利用多台机器的资源。
2. jdk的concurrentHashMap实现，内部分成了若干个槽，也就是若干个hashMap这些槽可以并发的读写，数据独立不互斥

• 任务分片

对处理的数据或请求进行分片，任务分片是对处理程序本身进行分片。类型归并排序

• 异步化与pipeline

1. 短信验证码登录或注册。
   客户端>发送验证码>应用服务器>消息队列>消息消费>http调用>短信平台

• 批量
• 串行化+多进程单线程+异步I/O