【浅谈】顶住高并发流量
- 前言：
各位少侠，相信前不久大家都经历了一次剁手，不知到土还够不够吃。哈哈哈哈嗝~ 但那天晚上相信是大厂技术人员不眠之夜，顶住亿级流量关乎到企业和商家的利益。那么今天作为一个了解也好or理论也好。带着我以前做分布式的一点小经验来一起学习一下服务架构部分演化。[大家面向领域不一样，我们点到为止，演化不完全]
timg.jpg
- 什么是分布式：
官方是这样解释的：系统中多个模块在不同的服务器上部署，即称为分布式系统。
个人理解：两个Tomcat或多个，分别部署在不同的服务器上。
- 什么是集群：
这个确实很难一下概括，因为也给别人讲过，术语多了不理解，术语少了又啰嗦[无奈]。
术语版：软件部署在多台服务器上并作为一个整体提供一类服务。
人话版：就是一群人共同完成一个事。
-
什么是负载均衡：
当系统收到请求时，系统上的各个节点能均匀的处理每个请求，缓解压力。
-
什么是反向代理：
我发送给系统请求，代理服务器又把这个请求转发到系统中的某台服务器，对于这个系统外部来说，与之交互的只是代理服务器，而代理服务器完成的是反向代理[怎么感觉有点绕，如果有问题请指出，嘿嘿嘿]
-
单机架构：
CSDN_1573523636109.jpg
哇偶~这是我在开始学JSP时候那个纯真年代！
说明：全部部署在一个服务器，解析域名后直接访问Tomcat服务。
瓶颈：随着用户数的增长，Tomcat和数据库之间竞争资源。 -
演化一：
CSDN_1573523638914.jpg
说明：Tomcat和数据库分别独占服务器资源
瓶颈：随着用户数的增长，并发读写数据库成为瓶颈。 -
演化二：
CSDN_1573523641443.jpg
说明：解决读写问题，最初是将经常加载的资源放到缓存里，这样能节省读写时间和资源。
瓶颈：并发压力主要落在单机的Tomcat上，响应逐渐变慢 -
演化三：
CSDN_1573523644024.jpg
说明：多部署几个Tomcat,利用反向代理来访问服务，悄悄告诉你一个Nginx并发是50000，一个Tomcat最多是100个，你算算反向到500个Tomcat不就能达到50000的并发量了嘛！
瓶颈：并发量的增长也意味着更多请求到数据库
- 演化四：
CSDN_1573523647980.jpg
像前面一样，对数据库的读和写分开，但是如果业务侧重点不一样怎么办呢？别着急，坐下！看下面！
-
演化五：
CSDN_1573523659193.jpg
侧重业务不一样，我们同理把业务分开就好了。到这里就有点向大企业服务结构靠近了。
-
后记：
其实后面还有一些演化过程，但考虑到做的方向不一样，掌握最基本的思想才是最重要的。就不再展开演化了。到此就结束了！
