如何设计一个高并发系统，现在这个是每个架构师都需要考虑的问题。当然每个人面对的业务场景都不一样，这里我们纯粹从技术角度探讨。我总结了下，要点如下：
- 负载均衡、缓存优先
- 服务拆分（系统拆分）、冗余扩容
- 削峰限流、熔断降级
- 分库分表、读写分离
一、负载均衡
负载均衡是首先，为接下来的系统拆分、服务拆分打下基础。统一入口，后面可以按需扩容，毕竟部署几十台服务器要比一台要强的多。服务端常用的有硬负载，比如A10、F5；有软负载，比如nginx。对于程序员来说见得负载基本都是软负载（毕竟硬负载太贵），nginx属于静态负载，不能动态扩容。后面还出了springcloud的robbin、dubbo的loadbalance等动态负载，可以动态扩容。针对纯前端也有CDN策略，可以加快静态图片、js等资源的加载速度。
nginx一般是首选，抗并发力强，稳定，插件多，还有限流、黑白名单等功能插件，会写lua脚本，nginx的性能会更强哦。
二、缓存
缓存是应对高并发访问的大杀器，毕竟访问内存比直接访问数据库要快的多，IO瓶颈得到极大解决，redis单节点轻轻松松几万并发。缓存的话现在常用的有reidis、memcached等。
按照并发量和可用性，缓存可以考虑做集群，以redis为例，部署9个节点的redis能抗住非常搞的并发量。当然用到缓存就有数据一致性问题，这也是要考虑好的问题。
三、系统拆分、冗余扩容（系统部署层面）
系统拆分是指将一个大系统拆成几个子系统，服务端分开部署，数据库也可以考虑分库，相当于在高并发场景下将巨大的流量分流。当然现在微服务很火，服务拆分和系统拆分相似。拆分的话可以考虑springcloud、dubbo等比较主流稳定的微服务框架。系统拆分后针对某几个高访问量的子系统可以多部署几台做冗余扩容，相应的并发性能也就上来了。
系统拆分或服务拆分涉及到系统的改造，也可以算是重构吧，微服务重构。重构完成后，并发量上来了，加节点就行了，可以抗的并发量可以成倍的提升。
四、削峰限流、熔断降级（服务层面）
削峰限流、熔断降级这个是我们留的后手，不得已而为之。比如某些秒杀的场景，缓存、拆分、扩容都做了，但是还是有康不多的风。这时候我们就舍小家保大家，针对流量洪峰，舍弃掉一小部分请求，保证后端服务的可用性。针对有些响应慢的服务，要及时处理掉，不然容易引起连锁反应，拖累好的服务，该下线下线，该降级降级。
削峰限流，用到的中间件当然就是mq了，kafka、RocketMQ、rabbitmq等，当然还涉及到集群的问题。熔断降级的话，dubbo有自己的实现机制，springcloud用的hystrix断路器组件。
五、分库分表、读写分离（数据库层面）
在访问到数据库前，虽然做了各种限制，但是数据库在一个高并发系统中早晚还是要抗一定的压力。考虑到访问的频率和数据本身的量级，分库分表、读写分离不可避免。
分库是指把数据库拆分为多个库，多个库来抗更高的并发；分表是指将一个表拆分为多个表，每个表的数据量保持少一点，提高sql查询性能；读写分离，比如在读多写少的情况下，主库写入，从库读取，搞一个读写分离，读流量太多的时候，还可以加更多的从库。
