架构是平衡的艺术，没有最优秀的架构，只有最合适的架构，没有实际场景的架构都是耍流氓。
某一天下午，老板找到正在工位的小王，“小王呀，公司仓库还有几十件自家产的商品，你去问问有没有人想要，就按照内部价三折吧”。小王一口答应，马上在电脑上新建了一个Excel，同时在公司内部群发送了内部促销的消息。不到一会，小王就陆续收到了广大同事的购买请求。小王按照先来后到的原则，在Excel中记录了那件商品，是谁买的，发货地址是哪。整理完成后，小王将Excel发送给了仓管助理，让他按照文档里的内容早点安排发货。
没过几天，老板又找到小王，“小王呀，上次内部促销反响不错，就是大家反应库存太少了。我决定以后每周安排一次内购活动，每次内购的商品你和仓库对接下。另外每次内购的商品都附上图片，方便大家更好地了解我们的产品”。小王一听这可犯了难了，公司那么多人，商品那么多，这要是每周都用Excel去登记，那该多费事呀。 于是小王找到了程序员小李，“小李呀，公司最近在搞内部商场，你帮忙做一个简单的电商软件吧，数据库就选那个免费的Mysql，越简单越好”。小李一口答应，“这个要点时间，我先做一版试试吧。”小王走后，小李默默地找到了自己的AI好兄弟。
在AI的帮助下，小李快速搭建了一个电商平台：
只使用一个mysql实例，这种被称为单库模式。 单库模式的最大优点是简单，开发快，好维护。缺点也很明显，如果数据库节点挂了，那么整个程序都将不可用。同时单点数据库能力有限，一旦访问量或数据量超过了单点数据库的承受上限，数据库分分钟会闹罢工。因此单库模式适合千万级数据以下，可以容忍程序一定时间内不可用的场景。
随着时间的发展，公司内购活动越做越大，逐渐发展成了整个集团的文化活动。活动不再集中于某一天，而是每一天。商品由定期上架调整为了不定期上架。这可苦了程序员小李，自从这破平台用的人多了，经常有人来说这个软件怎么经常卡呀。一旦平台用不了了，公司群里全是@自己的。没有办法，小李决定对整个平台进行升级。
改进后的平台使用三个数据库节点，其中主库用于数据的写入，两个节点通过binlog日志同步主库，用于数据的读取。电商应用通过分片中间件（如ShardingSphere）进行请求。这个就是Mysql大名鼎鼎的读写分离模式。
原来只有一个数据库节点干活，现在有三个兄弟一起干活，单个节点的工作压力大大降低。由于大部分数据请求都是读多写少的场景，因此大部分请求由两个从库一起分担。读写分离的缺点在于，整个架构的复杂度提高了，引入了分片中间件，增加了多个数据库节点，导致可能出现数据不一致的情况。
MHA集群架构
为了提升整个应用的可用性，可以在读写分离架构的基础上，引入MHA中间件，MHA可以监听mysql集群是否出现了故障，并提供自动转移故障的能力。 虽然MHA架构提供了高可用的方案，小李一想整个系统反正是工作时间正常就行，工作时间宕机了自己修修还算工作量呢，因此并没有选用。
随着系统的平稳运行，有一天小王找到小李，“小李呀，你说这个电商平台也不复杂嘛，你一个人就能搞定我们公司整个系统了，我们平时用的淘宝、京东之类的电商软件也是和这差不多么？”小李一听大吃一惊，“这可差的远了，首先用户量就不是一个量级的，咱们这运行了这么久，可能还比不上人家一天的访问量。”那互联网大厂的Mysql集群模式是怎么样的呢？
首先为了应对巨大的访问量，一方面需要对数据库底层进行优化，增强单个数据库的工作能力。另一方面必须引入更多的节点一起分担访问量，这就是mysql的分库分表模式。
应用请求的数据根据分片中间件的某种规则进行分发，由某个数据库分片进行对应的处理。常见的分片规则有
1、根据范围进行分片，如ID为0-10000000在分片1，ID为10000001-20000000在分片2，以此类推
2、根据地理位置分片
3、根据HASH方式分片
4、通过在数据中指定库表位的方式实现精准分片
实际生产中，我们可以将分库分表模式和读写分离的模式结合起来：
这个是互联网中主流的Mysql集群架构，具有高可用性，可扩展性。缺点也很明显，架构复杂度高，预算高，费时费钱费人。
