百万级访问量—高并发问题的解决历程

最新推荐文章于 2024-05-11 07:32:45 发布

zz_vim

最新推荐文章于 2024-05-11 07:32:45 发布

阅读量8.8k

点赞数 18

分类专栏：系统架构文章标签：高并发方案发展过程分布式系统演变数据库

本文链接：https://blog.csdn.net/zz_vim/article/details/89089122

版权

系统架构专栏收录该内容

1 篇文章 0 订阅

订阅专栏

一、单台服务器+数据库（原始）

二、增加反向代理

代理是一个接收和转发请求的过程。正常情况下，「正向代理」代理的对象是客户端，「反向代理」代理的对象是服务端，它完成这些功能：

健康检查功能，确保我们的服务器是一直处于运行状态的
路由转发功能，把请求转发到正确的服务路径上
认证功能，确保用户有权限访问后端服务器
防火墙功能，确保用户只能访问允许使用的网络部分等等

三、引入负载均衡器

反向代理还有另外一个功能：他们也可以充当负载均衡器。

Nginx经过配置，可以反向代理多台服务器。

部署多台Nginx（反向代理服务器），防止宕机，提升系统运行稳定性。

Nginx反向代理以及负载均衡配置参考：https://www.cnblogs.com/sixiweb/p/3988805.html

四、扩展数据库

负载均衡器的使用使得我们可以在多个服务器之间分配负载，但是现在所有的服务器还是使用的一个数据库进行存储和检索数据。我们可以用同样的方式，再扩展几台数据库出来，减轻存储检索压力，但是这里存在一个数据一致性的问题。

（1）主从模式或者单实例写多副本读

其中一台数据库负责数据写入修改，其他服务器负责读，这个方案的好处是保证了一致性，因为数据只能被单实例一台数据库写入，之后把写入数据同步到其他部分即可，所以该方案适合读多写少的情景。

I、如何进行同步？

通过使用消息队列进行异步数据同步，来实现数据的最终一致性。当然消息队列的各种异常也会造成数据不一致，所以我们又引入了实时监控服务，实时计算两个集群的数据差异，并进行一致性同步。

II、主从模式弊病

当主库DB1出现问题时，DBA会将DB2切换为主库，并通知项目组，项目组使用DB2替换原有的主库DB1，重启web服务器，这样web服务将使用新的主库DB2，而DB1将不再被访问，整个数据库服务得到恢复，等DBA修复DB1时，再将DB1作为DB2的从库即可。

这里有个很大的问题，就是不管主库或从库出现问题，都需要DBA和项目组协同完成数据库服务恢复，这很难做到自动化，而且恢复工程也过于缓慢。

所以数据库如何做到高可用呢？

高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。

如上图所示，web服务器将不再直接连接主库DB1，而是连接KeepAlive虚拟出的一个虚拟ip，再将此虚拟ip映射到主库DB1上，同时添加DB_bak从库，实时同步DB1中的数据。正常情况下web还是在DB1中读写数据，当DB1宕机后，脚本会自动将DB_bak设置成主库，并将虚拟ip映射到DB_bak上，web服务将使用健康的DB_bak作为主库进行读写访问。这样只需几秒的时间，就能完成主数据库服务恢复。

同样的，web服务器将不再直接连接从库DB2和DB3，而是连接LVS负载均衡，由LVS连接从库。这样做的好处是LVS能自动感知从库是否可用，从库DB2宕机后，LVS将不会把读数据请求再发向DB2。同时DBA需要增减从库节点时，只需独立操作LVS即可，不再需要项目组更新配置文件，重启服务器来配合。

（2）分库分表操作

参考：https://www.cnblogs.com/zhangj391/p/6715410.html

https://www.jianshu.com/p/32b3e91aa22c

五、微服务

将所有服务放在一个服务器上，放在一个JAR包，降低了复杂性，但是随着规模的增加，事情会变得复杂和低效，更多的开发人员加入进来，在同一台服务器同一个项目代码里面进行开发，造成的冲突会越来越多，互相依赖性太高，同时不利于新入开发人员阅读理解代码。

这时候微服务架构产生了。

每个服务都可以单独扩展，更好地适应需求
开发团队之间相互独立，每个团队都负责自己的微服务生命周期(创建，部署，更新）等。
每个微服务都有自己的资源，比如数据库，进一步缓解了数据库的问题。

微服务的划分大多是基于业务进行拆分，实现低耦合。

六、缓存和内容分发网络（CDN）

网络应用的很大一部分由静态资源构成,如图片、CSS样式文件、JavaScript脚本以及一些针对特定产品提前渲染好的页面等，通过使用缓存，对于一些客户的请求，不一定都去重新处理一遍，使用缓存，提高访问速度。

缓存的加强版叫内容分发网络（Content Delivery Network），遍布全球的大量缓存。这使得用户可以从物理上靠近他们的地方来获取网页内容，而不是每次都把数据从源头搬到用户那里。

七、消息队列

将客户的任务请求放到一个队列当中，进行管理任务，优点：

解耦了任务和处理过程。有时需要处理大量的图片，有时很少。有时有大量服务可用，有时很少可用。简单地把任务添加到待办事项而不是直接处理它们，这确保了系统保持响应并且任务也不会丢失。
可以按需扩展。启动大量的服务比较耗时，所以当有大量用户上传图片时再去启动服务，这已经太晚了。我们把任务添加到队列中，我们可以推迟提供额外的处理能力。

八、总结

大道至简，不管采用什么方案，优化的根本都是分而治之，大事化小，小事再化小，没有啥是一个中间件解决不了的，如果有，那么再加一个！

九、参考资料

高并发数据库设计 https://www.cnblogs.com/zhangj391/p/6715410.html

从单个服务器扩展到百万用户的系统 https://mp.weixin.qq.com/s/wSCeO8QVYniMIGcBFDZyjw

数据库扩展性架构设计 http://mp.weixin.qq.com/s/gI6j_TyjJ4jEb-i8HstFaw

分库分表需要考虑的问题及方案 http://www.jianshu.com/p/32b3e91aa22c

无限容量数据库架构设计 https://mp.weixin.qq.com/s/ad4tpM6cdi9r6vgfbaTzxg

MQ消息可达性+幂等性+延时性架构设计 http://mp.weixin.qq.com/s/8oX7u8XcLL80_nNdN-UkvQ

高可用+高并发+负载均衡架构设计 http://mp.weixin.qq.com/s/_I2SNfcAF0kPsRkZLs0uZg

数据库秒级平滑扩容架构方案 http://mp.weixin.qq.com/s/BLOneOs-cPxP_9b5eH8oQA

100亿数据平滑数据迁移,不影响服务 https://mp.weixin.qq.com/s/Ozqu2A7Sy_TGKkF6yF1rDQ

一分钟掌握数据库垂直拆分 http://mp.weixin.qq.com/s/ezD0CWHAr0RteC9yrwqyZA

5kw数据量，如何为表增加一列 http://mp.weixin.qq.com/s/HmTbhqS1QCAuPYrccdpwZw

互联网在线表结构变更 http://mp.weixin.qq.com/s/JJjLgNX3ZawwWkguP5iHVA

58同城，1万属性100亿数据量数据库架构设计 https://mp.weixin.qq.com/s/3O3kPSwV-tAeYdy2ZRACpg

zz_vim

关注

18
点赞
踩
92

收藏

觉得还不错? 一键收藏
4
评论
百万级访问量—高并发问题的解决历程

目录一、单台服务器+数据库（原始）二、增加反向代理三、引入负载均衡器四、扩展数据库五、微服务六、缓存和内容分发网络（CDN）七、消息队列八、总结九、参考资料一、单台服务器+数据库（原始）原始架构二、增加反向代理反向代理代理是一个接收和转发请求的过程。正常情况下，「正向代理」代理的对象是客户端，「反向代理」代理的对象是服务端，它完成这些功能...
复制链接

扫一扫