我也要谈谈大型网站架构之系列（4）——分布式中的异步通讯

我也要谈谈大型网站架构之系列（4）——分布式中的异步通讯

 

　　咱们知道在面向对象编程中，总会想着各类办法来实现代码的解耦，从而让项目中的各类人员面对本身熟悉的业务进行开发，

作到术业有专攻，好比你们很是熟悉的三层架构，MVC，MVP以及MVVM模式，让前端设计专一于html的制做，让后端开发人员

更加专一于业务逻辑的编写，能够看到，咱们这么作的目的就是想最大程度的作到系统的可扩展和可维护性，那么咱们的大型网站

是否是也要遵照这种模式呢？

 

一：分层和分割

1：分层

    对于分层，咱们可能很是熟知了，数据访问层，业务逻辑层，缓存层，应用层，层层专一于本身的业务，而后根据须要创建起

 各自的集群，各自分离部署，而从达到系统的扩展性和维护性。

 

2：分割

    若是说前面是横向切割，那分割就是纵向切割，咱们能够把网站的总体业务切分红不少的小业务，好比博客园的导航栏，咱们都

能够认为是一个独立的网站，配上各自的二级域名，创建各自的集群来实现系统的扩展性，固然这个粒度可大可小。

若是说这些子网站不存在相互调用，那么咱们新增模块或者修改模块基本上都不会对其余模块形成影响，这也是咱们作扩展性的终极

目标，如今既然都作到解耦了，下面的目标就是作如何通讯了，通讯能够分为“同步”和“异步”，这篇主要是讨论下异步操做，在分布式

系统中作到"异步操做“，固然少不了强大的消息队列。

 

二：消息队列

    在分布式的系统中使用消息队列后，咱们的生产者只管向消息队列中甩完数据后当即返回，而不论是哪一个消费者来消费，能够看到

其实消息队列有以下三个优势。

 

1.  加快网站的相应速度

　   这个刚才也说了，应用层直接把消息给消息队列而后直接返回调用端，这样就避免了处理复杂的业务逻辑而后同步的插入到数据

  库后再返回形成的响应延迟，在不少网站上用户提交订单就是这么处理的，应用层生成一个订单号以后，将订单丢给消息队列，而后

  直接到订单成功页面，此时后端消费者对订单尚未处理完毕，由于后面会有比较多的数据操做，好比减库存，数据库同步等等，而

  用户若是想要看到订单详情，须要点击“订单号”才能进入到订单详情页，这种处理也是由于消息队列的非及时性，因此须要获得网站

  设计方改进和支持。

 

2. 提供系统的可用性

    既然是异步操做，就形成了生产者不知道消费者的存在，而反过来消费者不知道生产者的存在，若是消费者挂了就不会影响到生产者，

  生产者还会照常无误的向消息队列甩消息，当消费者恢复正常后就会继续消费消息队列，系统的表现可能就是email或者短信延迟收到，

  不会对系统形成太大的影响。

 

3. 并发削峰

   既然是大型网站就免不了高并发的读写操做，很典型的一个例子就是电商中的秒杀，这种高并发的写操做，若是一会儿都涌入到数据库

里面去了，会致使数据库的压力很是大，从而致使客户端的访问延迟，就是不挂也容易形成数据库的死锁从而形成不少灵异事件，遇到这

种一拥而入的状况，咱们就必须进行线性化操做，在代码层面上咱们能够用lock机制来串行化，在分布式中咱们用“消息队列”来串行化，

并且还能够经过逻辑操做来对消息队列进行动态的防洪，控洪。

 

 在消息队列的选择上，微软有本身的MSMQ，可是在大型网站中，咱们的消息队列一样须要集群，而且但愿能跑在内存中，而且支持序列

化硬盘，同时在“伸缩性”和“可靠性”上要有好的做为，因此推荐你们用用开源的RabbitMQ，网址：http://www.rabbitmq.com/  不过很

多公司都有本身开发的消息队列，好比携程的CMessage，淘宝的MetaQ。