做一个不崩溃的icode9核酸系统有多难？

本文主要是介绍做一个不崩溃的icode9核酸系统有多难？，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

热度已经过了，但还是觉得有必要从架构设计的角度来讨论一下此事。并用以往我的经验来设计一套负载能力更好一些的系统。

先说一下基本的架构思路：

1. 最大限度的避免计算，静态化
2. 不用数据库，更新类操作使用APPEND模式的文本文件
3. 流程最短，最好是客户端访问的第一台服务器就能完成全部工作
4. 善用CDN
5. 客户端负载均衡

需求分析

1. 扫码：通过调用URL将人访问过该地址的信息记录，以便有出现阳性时追访
2. 获取当前人的健康码状态，显示到页面

页面中显示的字段信息包括：

1. 健康码状态：绿码/黄码/红码等
2. 最近一次核酸至今的时间：1天
3. 疫苗接种情况
4. 基本身份信息：姓名、身份证号
5. 时间：查询时间，失效时间

常规设计思路与失效

一个只设计过常规MIS系统的工程师，满足如上需求的常规做法如下：

1. 建立数据库，分别用几个表格来记录用户信息、核酸记录、疫苗记录、到访记录
2. 用户扫码提交到访信息，就在到访记录表中INSERT一条新的记录
3. 健康码页面的显示，依次去查询如上四个表来获取结果，其中后三个表需要排序后显示创建日期最新的记录
4. 祭天，上线

然后遇到流量冲击，系统崩溃。崩溃的原因分为几个：

1. 提交到访信息时，数据库只能承受几十到几千QPS的INSERT请求，对其他扫码请求无法处理，导致用户提交的请求失败
2. 四个表的查询，对数据库造成了巨大的查询压力，数据库服务器LOAD爆了

资深架构师的改造思路

5-10年经验的工程师/架构师的典型改造思路：

1. 数据库横向拆表到多个数据库服务器，每个数据库按照一定的负载均衡逻辑，只保留一部分数据，比如用户ID整除10后的余数，分布到10台数据库。于是工程师熬夜加班，确保查询时会根据负载均衡逻辑去正确的服务器查询，提交到访记录时也会INSERT到正确的服务器
2. 入口加负载均衡，DNS解析到多个机房的入口Load Balance，然后Load Balance再随机分派给多台后端服务器，多堆服务器提高处理能力
3. 数据冗余降压力：把最新一条的核酸记录、疫苗记录，作为冗余字段写入到用户表里，这样显示健康宝页面时就少查询了两个表
4. 查询时间、失效时间，两个字段在客户端生成，不问数据库要
5. 搞个消息队列，先返回给用户查询中，等个未知的时间都算完了再返回

通过这样一套操作下来，整个系统的负载能力能获得几十倍到几百倍的提高。

但很不幸，有些时候就是会有数千倍甚至数万倍的流量涌过来。

首问负责制

想要更强的负载能力，就需要若干改造思路。

所谓首问负责制，是让用户的请求尽量在第一个服务器就得到全部的满足。如果不行，也要尽最大能力降低完成一个请求经历的服务器数量。网络通常是整个系统里最慢的部分，服务器之间的互相调用也会严重的影响系统负载能力。

所以目标就是，让用户访问的第一台服务器就完成提交到访记录、获取用户健康宝全部信息。

标签：系统,安装,命令,方式,配置,二维码,数据库 来源：

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

这篇关于做一个不崩溃的icode9核酸系统有多难？的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！