大型网站系统与Java中间件实践

2019独角兽企业重金招聘Python工程师标准>>>

分布式系统简介

分布式系统有很多节点，且这些节点协同工作。

线程与进程的执行模式

1、线程的执行模式：互不通信的多线程模式；基于共享容器协同的多线程模式，如经典的生产者和消费者模式；通过事件协同的多线程模式，如锁机制，wait,notify。

2、多进程的执行模式。线程是属于进程的，一个进程内可以与很多线程共享了进程的内存空间，而多个进程之间是相互独立的，所有多个进程间的通信，交换数据的方式与多个进程间的方式会有所不同。两点不同：1.1多个进程相对多个进程来说，资源控制方面会比较容易实现。1.2多个进程中的单个进程出现问题，也不会造成整体不可用。多进程间可以共享数据，但是其代价要比多进程要大，会涉及序列化与反序列化的开销。而分布式系统相当于把单机的多进程变成了多机的多进程。

网络IO实现方式

BIO，NIO，AIO，其中NIO是采用轮询的方式来监听处理IO请求，而AIO采用时间通知的方式来处理IO请求，可以参考：http://blog.csdn.net/anxpp/article/details/51512200

分布式系统中控制器的种类

控制器中的作用是协调分布式系统中各个节点之间显得动作和行为。 1、硬件负载均衡

2、软件负载均衡（LVS），有时候也叫作透明代理，优点代价低，可控性强，即可以按照之间的需求去增加负载均衡策略。缺点：有延时，要经过中间代理；处于必经路上，如果发生问题，影响较大。输入图片说明

3、采用名称服务，与透明代理最大的不同是，在请求发起方和请求处理方中，没有代理服务器这样的设备存在，而是请求发起方和请求处理方直接连接。“名称服务”的作用是一是收集提供请求处理的服务器的地址信息；二是提供这些地址信息给请求发起方。名称服务只是起到一个地址交互的作用，在发起请求的机器上，需要根据从名称服务得到的地址进行负载均衡。也即，原来在透明代理上得工作，被拆分到了名称服务和发起请求的机器了。输入图片说明

4、规则服务。在请求发起的机器上，会有对规则进行处理从而进行请求处理服务机器选择的逻辑。在此，规则服务器并不直接和请求处理机器交互，而只负责把规则提供给请求发起的机器，然后让请求发起机器自行处理。

输入图片说明

5、 Master+Worker 的方式。这种方式更多的是任务的分配和管理。

输入图片说明

运算器的变化

1、使用DNS选择运算器，用户发请求到DNS上，DNS告知服务器地址输入图片说明

2、负载均衡。DNS统一返回负载均衡的地址，然后负载均衡去请求真正的服务器。输入图片说明

分布式系统的难点

1、缺乏全局时钟2、面对故障独立性3、处理单点故障（在整个分布式系统中，如果某个角色或者功能只有某台单机在支撑，那么这个节点成为单点，其发生的故障称为单点故障）4、事务的挑战

单机走向集群时，session的处理方案有:1、session sticky,即每台服务器上只保存各自的session,通过负责均衡服务器，保证同一个会话落在同一个服务器上 2、session Replication 。每台服务器搜保持所有的session .(要注意同步session）3、session 数据集中存储。不同的服务器从同一个地方读取session .将session剥离开，单独进行管理。4、Cookie Based ，改方案是通过Cookie 来传递session 数据。目前我们公司就是采取这种方案，但是也有不足，如Cookie长度限制，安全性，带宽消耗（每次请求都要带上session）,性能问题（每次Http请求和响应都会带上session,对于web服务器来说，在同样的情况下，响应数据减少了，支持的并发请求减少了）。

引入中间件后的架构图

输入图片说明

服务框架

服务化的好处，首先从结构上来看，系统结构更为清晰了；从稳定性来看，一些散落在多个应用系统中的代码也编程了服务，并由专门的团队进行维护，一方面可以提高代码的质量，另一方面由于核心的相对稳定，修改和发布的次数会少，这也可以提高稳定性。最后更加底层的资源统一由服务管理，结构更加清晰，也更加利于提高效率。

服务调用端

输入图片说明

其中协议适配，协议包括两部分，一是用于通信的数据数据报文的自定义协议（如Http ),一是，远程过程调用本身的协议（如在服务调用中的具体协议，需要自己来订单，可以选择XML作为序列化的方式）。

网络通信实现，可以有使用NIO，其中有1、OneWay是一种单向的通知。2、Callback 则是回掉，是一种很被动的方式，Callback的执行不是在原请求线程中3、Future，是一种能够主动控制超时，获取结果的方式，并且它的执行仍然在请求线程中。4、可靠异步传输，一般是通过中间件保证的。

服务提供方

输入图片说明

整个服务化框架的功能分为服务调用方和服务提供方，此外像序列化，协议，通信等是公用的模块，在具体的实现上，是把这些功能放在一起形成一个完成的服务框架，而不是分为服务调用者框架和服务提供者框架，因为某个服务调用者的服务提供者，可能是另一个服务提供者的调用者，两者是相对的。

数据访问层

数据库垂直/水平拆分的问题垂直拆分：分库；水平拆分:分表。垂直拆分的影响：1、单机的ACID保证被打破了，原来单机的事务被打破。2、一些Join操作会变得困难3、靠外键去进行约束的场景会受影响

水平拆分的影响：1、打破ACID;2、join 3、外键 4、依赖单库的自曾序列生成唯一的ID会受影响 ‘5、针对单个逻辑意义上的表的查询就要跨库了。

分布式事务概念

分布式事务AP/TM/RM关系

输入图片说明

DTP模型

输入图片说明

大型网站的一致性基础理论 CAP。 C:一致性 ;A 可用性；P（分区容忍性），一般大型网站选用AP组合，但会保证最终一致。

多机的Sequence问题与处理

就是id的问题，要考虑：唯一性和连续性问题。

我们把素有的Id集中放在一个地方进行管理，对每个Id序列独立管理，每台机器使用Id时，从这个Id生成器上取。要注意：1、性能问题 2、生产器的稳定问题，3、存储的问题

Join问题解决方案：1、业务层改变，不使用join 2、数据冗余，保证在一个表中差3、使用搜索引擎。

分库分表后的问题：1、排序 2、函数处理 3、求平均值 4、非排序分页 5、排序分页

不同接口数据层结构

输入图片说明

数据层的整理流程

SQL解析->规程处理->SQL改写->数据源选择->SQL执行->数据集返回合并处理。

数据层结构图

输入图片说明

###** 消息中间件**

消息中间件的意义，带来了异步性，对系统进行解耦。

消息中间件中要着重考虑的是消息的顺序保证、扩展性、可靠性、业务操作与消息发送一致，以及多集群订阅者等方面的问题。

消息发送一致性：是指产生消息的业务动作与消息发送的一致，即，如果业务操作成功了，那么由这个操作产生的消息也一定要发出去，否则就是丢失消息；另一方面，如果这个业务行为没有发生或者失败，那么就不应该把消息发出去。解决方案输入图片说明消息一致性补偿

消息中间件与使用者的强依赖问题。 1、提供消息中间件系统的可靠性，但是没有办法保证百分百可靠2、对于消息中间件系统中影响业务操作进行的部分，使其可靠性与业务自身的可靠性相同（可将业务DB与消息DB放在同一个数据库中，使用事务保证）3、可以提供弱依赖的支持，能够较好地保证一致性。(如：轮询消息，采用本地磁盘存储消息）

消息模型对消息接收的影响 1、JMS Queue模型，该模型中多个应用接收不同的消息；2、JMS Topic 模型，多个应用接收同一份消息，消息会重复被接收。在实际运用中，我们会结合两者用。如：不同的集群中采用topic模式，集群内部采用Queue方式。

保证消息可靠性的做法 输入图片说明

从图看出要保证三方面：消息发送端的可靠性，消息存储的可靠性，消息接收端的可靠性。

订阅者视角的消息重复产生和应对消息重复产生的原因：1、是发送端重复发消息（如：消息中间件接收了消息，但是发送端并未受到确认，确认超时等） 2、消息中间件重复投递消息给消息接收者应用（消息接受者应用成功处理消息，但消息中间件未得到确认）；

解决方案：1、采用分布式事务（比较复杂）2、要求消息接收者来处理，对消息的处理具有幂等性。

保证顺序的消息队列的设计 有些时候，我们需要消息队列消费的时候是被顺序消费的。

输入图片说明一个消息接收者在每一个它所接收的消息队列上有一个当前消费消息的位置。对于这个接收者来说，这个位置之前消费的消息就已经完全消费了。在同一队列中，不同消费者维持自己的指针，并且可以同指针回溯。

消息的Push和Pull方式

push方式是服务端推送的方式，而pull是消费端主动去获取的方式。

软负载中心与集中配置管理

软负载中心的两个作用：1、聚合地址性 2、生命周期感知。

软负载中心的结构：1、软负载中心的服务端，主要负载感知提供服务的机器是否在线，聚合提供服务的地址信息，并且负载把数据传递给使用数据的应用2、软负载中心的客户端：作为服务提供者，主要把服务的具体信息主动的传给服务端，并且随着提供服务的变化去更新数据；而作为服务使用者，向服务端告知自己所需要的数据并负责更新数据，还要在本地进行缓存数据。输入图片说明