标签：基础 async 解决 连接 tin 问题 重启 syn 业务
谢邀，这是个好问题，而且这个问题好在即使概念非常容易理解，但是这几个不同的概念细节太多太多，
而且理解了概念，自己要用，又需要做很多的调研评估和开发工作。作为在这个领域爬坑多年的人，我这
里就先介绍下概念，再提供几个开源工具和云服务吧。
先来说这些架构解决的问题吧，传统数据库如Mysql（以下工具也会以Mysql为主），存在的问题就是单
机部署，单进程，这样就存在一些问题：
资源利用不灵活，有可能cpu的性能还有富余，但是磁盘已经顶不住读压力或写压力了，有可能磁盘的性
能还有富余，但是cpu的性能已经顶不住了。还有可能cpu和磁盘都很富余，但是写入的数据量太大，直接
撑爆磁盘上限。
资源有最大上限，cpu最多用到比如64核的机型，磁盘最高几百T，再高的话不好意思，没有更屌的机器
了，但是用户的数据和查询是没有上限的。
连接池资源的上限，为何要把连接池单独提出来说，原因就是业务量一大，
容灾类的问题，虽然事务可以保证重启后数据不丢，但是业务线上跑，重启等不起。
而这个问题所提的几个概念，正是对如上传统数据库痛点的解决方法。
主从复制（replication），解决的是容灾类的问题，容灾需要保证数据库切换的实时性和数据的一致性，
一致性的强弱还催生了几种不同的复制模式（asynchronous, semisynchronous, group replication)
读写分离（read write spliting），是一种业务类应用解决读流量单机无法承受的方式，学名叫 scale out
，读写分离类的业务是架设在主从复制的基础上
负载均衡 ( load balance)，也是一个非数据库的概念，但是在数据库层面，如果有一个通用的中间层，那
么也适用。
这三者的关系基本可以参考这几幅图：
这幅图的load balance做在了业务层，而读写的路由逻辑由业务层在控制。
标签：基础 async 解决 连接 tin 问题 重启 syn 业务
原文地址：https://www.cnblogs.com/shan1393/p/9064102.html
