8 如何设计一个高并发系统

这个话题很大也很泛，我们这里泛泛而谈下。主要关注下面的几个点

系统拆分的问题

系统拆分主要垂直拆分和水平拆分。
水平拆分稍微简单点，把技术相关的基本功打扎实了，常见的水平拆分的方式大体有个了解以后，大部分人做起来基本上问题不大。我们在进行水平拆分服务的时候尽量考虑一些请求数据状态的问题。比如说我们一个用户体量很大的系统在用户登录的时候，是在服务端保持用户登录的状态信息，还是把状态信息放在token中在网关统一解密，如果在服务端保持用户的登录状态信息，当我们的用户体量不断的增加，我们如何存储，存储的是否能支持扩容，性能和稳定性的问题。当我们去分析这些问题的时候，我们需要从一个逻辑体系往下分析。这就涉及到思考问题的普遍方法论的问题。
如果我们把登录信息放在token中在网关统一解密，这个就涉及到用户信息安全的问题，用户关键信息是否保存，等等。如果做成无状态的服务我们完全可以很方便的进行扩容。

如何做垂直拆分呢？面对一个大型的业务复杂的系统，一般需要考虑垂直拆分的问题。那么我们的垂直拆掉是否根据业务去拆，如何做DDD领域建模的问题。如果按照节约机器的方式，我们是要不要按照CPU密集拆，内存密集型拆等等。我们每一种拆分的方法都需要基于一个逻辑体系去细化这些问题。

这就涉及到我们聊架构设计相关的第一篇文章，我们需要锻炼我们思维方式的方法论的问题。这个话题也很泛，有机会我单独挑这个话题来聊。

为什么要分库分表

我们知道一个数据库的进程也是由数据库的引擎程序去执行我们的sql语句操作的，也就是说当我们对数据库的操作过于频繁的时候(并发高的情况下)，执行引擎也是处理不过来的，这个时候我们就要考虑分库的问题，如果只是数据库比较大但是操作并不频繁，这个时候引擎程序是能够处理的，但是由于需要从磁盘找数据，这个是比较耗时的动作，这个时候我们需要考虑分表的问题。

缓存的问题

在读多写少的场景会大量的使用缓存，但是在使用的时候要考虑到雪崩、穿透的问题，数据库和缓存一致性的问题。redis单机就能达到几万的qps，而数据库即使优化的情况下也才2000以上的qps。使用缓存会大量节约资源

消息队列的使用

消息队列的使用场景很多，在削峰、分布式解耦、异步处理、通知等场景都会用到。使用消息队列需要注意幂等的问题，消息积压的问题等。

数据库的读写分离

在大部分的业务场景中，数据库都是读多写少的场景。我们可以使用读写分离、HA、主备等技术对数据库进行处理。

全文搜索

es是一个通过倒排索引的方式提供搜索并能够无限的扩容，具体es的架构后面我们会聊。

具体的高并发、高可用、高性能的系统我们需要根据具体的业务去看，不能一概而论。还有我们做架构的整个一个逻辑体系和方法论的建立也不是一朝一夕的事情，不但需要我们不断的去学习，而且还有有强大的总结能力，提炼方法论的能力。