高性能高并发高可用系统设计思路

机会是留给有准备的人，当机会来临的时候，没有准备好才是最大的悲哀

一般电商系统可能会有过亿用户量，一天流量几十亿，高峰期并发量几万十几万，系统如何架构？系统架构是根据业务走的，业务越复杂，系统架构难度就越高。Mysql数据库每秒并发两三千，再多一些可能扛不住压力就挂了。如何做到高并发？

系统拆分

把系统按照一定的业务规则拆分为多个服务，每个服务独立数据库，一个库变成了多个数据库，也可以扛高并发。

分库分表

然后针对业务量比较大的服务中心再做分库分表，将一个数据库拆分为多个库，多个库来扛更高的并发，将一个表拆分为多个表，提高sql跑的性能。

读写分离

有些服务中心的业务数据可能读多写少，做一个主从架构，主库负责写，从库负责读，增加更多的从库来提高读并发。

缓存

大部分的高并发场景，都是读多写少，数据库数据更新到缓存，读的时候走缓存，写的时候走数据库然后数据更新到缓存。Redis服务器单机并发支撑量几万，然后再做个集群和主从架构。

MQ

如果有高并发写的场景，用redis来承载写那肯定不行，redis是缓存，数据随时就被LRU了，没有事务支持。可以把大量的写请求放MQ里异步排队写，后边系统消费后慢慢写，控制在mysql承载范