分布式集群怎么理解(分布式服务器集群搭建)
如今项目架构的特点
1.分层开发
2.MVC架构
3.服务器分离部署
集群
集群架构
特点:
1.项目采用多台服务器集群部署
2.mysql数据库采用多台服务器集群部署
优势:
1.并发量提高(1000+)
2.容错性提高(具有高可用性)
但是,我们发现这种集群部署存在两个问题,什么问题呢?
1.session如何共享?
我们都知道,session是会话,即一个用户访问服务器的时候,就会产生一个session,这个session会一直伴随着这个用户的访问全程,直到用户关闭浏览器结束这次会话,如果用户访问服务器时,这台服务器挂掉了(宕机),那么原先保存在这台服务器上的session也肯定挂掉了,那么就会产生一个后果,就是这个用户原本访问好好的,现在突然session没有了,而session没有了就意味着需要用户重新登陆才能进行一些相应操作,这显然是不行的,这样的服务用户体验实在太差了,两种解决方案:
第一种解决方案:
用Tomcat集群复制(广播模式)来共享session:
这种解决方案是利用Tomcat来进行集群复制,把每个服务器上的session都共享式的都复制一遍,保证每个服务器上都有着一个用户的session数据
应用场景:在传统项目中一般这么应用,因为传统项目的用户量少,可以承担压力,但当到互联网项目时,这种方式就绝对不可取了,打个比方,比如用户量有100万,那么就需要在每个服务器上都复制这100万个用户的session,这样做显然会极大的消耗系统资源,使系统变得极为臃肿和不稳的,所以在互联网项目里是绝对不会采用这种方式的
缺点:当有大量用户时,服务器的压力会亚历山大,所以只适合用户访问量小的传统项目
第二种解决方案:
用第三方redis服务器来存储session
用这种方式来存储session的话,只需当前正在使用的项目把所有session都放在redis里面,当有其他项目需要使用时,就可以直接从redis中直接获取session,从而解决了这个问题。
2.这么服务器,请求该往哪发送?
用nginx服务器来分发请求,实现负载均衡。
虽说集群能够解决部分问题,但并不能解决所有问题,无论是从公司成本还是运营成本来说,显然这种传统的集群架构是不适应现在的互联网行业的,而且对于一般的公司来说也不可能去花大价钱做这种布置。
所以,这种情况下我们就必须对我们的架构来进行优化了,那么如何在服务器只有一定数量的情况下,让我们的项目的成本能达到一定控制,并且让我们的项目达到一个最优化的并发的访问量呢?那么就需要对现有的这种架构进行再次拆分,让我们的项目成为面向服务的分布式架构。
面向服务的分布式架构(SOA):
1.webserver
如图所示,第一种方式还是有着明显的缺点的,如服务层的网络抖动或是服务层进程繁忙,可能有人对这两个名词不太理解,这里就解释一下:
网络抖动:当有大量用户访问时,可能会出现service层的延迟现象,而web层因为长期得不到响应,则会抛出时间超出异常
进程繁忙:这个的意思和前边的差不多,都是指service层业务太多,顾不上web层的请求,web层的请求就只能一直在那等着,时间长了也就抛出超时异常了
2.dubbo
原理讲解:看了第一种webservice的方法之后,我们采用了第二种方法,即dubbo这种中间件的方式,采用这种方式有什么好处呢?
好处:
当服务器启动时service会把所有的对象通过dubbo注册给zookeeper,而以后每次需要请求获取对象时,就可以直接从dubbo中异步获取,不需要再去访问service层,这样就解决了
服务层网络抖动和服务层进程繁忙的弊端。zeekeeper可以看成是一个数据库,用来存储数据的,具体的原理以后会专门开篇文章描述它。
这种方式是目前最常用的,起码是我最常用的,顺嘴一提,dubbo是阿里巴巴开发的一款中间件,性能强大。
总结分布式架构特点:
优点:
1.大幅提高并发访问量
2.可以节省开发成本
3.实现了服务层与表现层的解耦合
原创文章,作者:admin,如若转载,请注明出处:https://www.qq65hfghe5.com/tg/102286.html