拯救系统——读写分离的运用

【介绍】

本人是一个测试工程师，主要负责接口以及性能方便的压测，目前在一家医疗数据公司任职，既然是做医疗数据，所以主要公司的主要业务就做是医疗软件。

去年年底公司为医学信息中心开发一款（深圳市核酸采样登记服务系统），由于急需部署使用，整个项目开发、测试上线用了10几天，随着疫情的逐渐被控制住，所以该系统使用的医院（用户）并不频繁。直到今年的6月份，由于广州、深圳，开始出现疫情，深圳的所有区域开始设置采样点，进行核酸采样，系统出现了很大的问题，系统奔溃导致采样的工作人员不能正常使用小程序登记数据，只能暂时采用手动登记的尴尬局面。

【系统介绍】

《深圳市核酸采样登记服务系统》该系统使用前后端分离架构，具体什么技术实现就不详细介绍了（实际我也不太懂），该系统部署在XX中心，5台应用服务器（有做负载均衡），3台数据库服务器（主从），2台nginx服务器（主从）

直接就说说该系统业务逻辑吧：

Web后台（医院或者机构）——授权——小程序（采样工作人员）（就是我们做免费核酸的时候要我们出示深I您二维码他扫描）——然后再扫一个管条码（放我们被棉签捅了喉咙的样本管）——数据库——Web后台（医院或者机构）查看自己授权的工作人员的采样数据，并使用数据。

【事件发生】

由于深圳陆续出现几例新冠患者，政府启动第一轮全市人员排查，所以当天数据非常多，到了晚上数据库达到100万条数据，各个区域的医院以及机构正在查数据，导数据，发现非常的慢，不一会儿小程序也无法存入数据，客户就立马打电话让我们排查原因，以及修复问题，这个时候已经是晚上11点了，经过几小时的排查处理，发现是查询数据较多导致，优化SQL后，明显改善了不少，但是数据量大的情况也不是很好。

具体原因——几十家医院机构在查数据，导出数据，一直在等待中，然后数据库服务器一直CPU满载，因为不是做的负载均衡，导致数据库崩溃，小程序，存数据就报错，最后导致采样的工作人员手动登记了几小时，大大增加了别人的工作量，毕竟这个查询的接口我是压测过的，不过只是在数据量非常小的情况下，惭愧！

【解决方案】

第二天商讨解决方案，主要原因处在数据库，那就在这上面下功夫，毕竟用的免费的Mysql数据库，都说便宜没好货，估计是这样吧，所以也不敢贸然使用3台数据库服务器作为负载均衡来解决问题。最后各领决定使用（读写分离）来解决这个问题，具体逻辑就是，把3台数据库服务器都使用起来，一台用于小程序写入数据，一台用于Web后台查询数据，导数据，另外一台是作为同步数据的处理。

添加描述

这种方式就就算数据量大，后台查询数据、导数据导致数据库服务器崩溃也不会影响小程序的的使用，加上工程人员、DB数据的工程师配合，及时处理查数据导数据出现的问题。

经过1天的修改程序，测试，最后更新到生产环境上，连续一个星期，每天上百万数据，没再出崩溃的事故了，不过期间还发生另外一个问题，Mysql出现了锁表，但是这个收到消息后，10分钟就解决了。

政府要求排查多轮，同时还会开放自主扫码登记的功能，所以接下来全市做核酸的会更频繁，数据更多，担心程序会不会再出现事故，影响效率，所以与腾讯合作在腾讯云上加大服务器资源配置，重新部署一套满足全市人民使用的环境，到时数据库也会切换成Oracle，读写分离同样使用在腾讯云的环境上，以下是部署环境的拓扑图：

添加描述

【期待】

各位大佬还有没更好的解决方案？欢迎来探讨。