统一配置中心实现系列-基于长轮询的实现
系列文章：
统一配置中心实现系列-定时任务
统一配置中心实现系列-Zookeeper和Ignite
目录
一、前言
在前面的文章中，我们一次介绍了统一配置中心基于定时任务的实现和基于Zookeeper&Ignite的实现。本文将介绍一种类似Zookeeper一样基于中心化的实现。但是我们并不使用任何类似于Zookeeper的第三方集群组件，而是自己来实现一个基于长轮询的"Zookeeper"。
二、名称介绍
1、长轮询
长轮询即Long Poll。这是基于Http请求的一种称呼。我们一般所说的http请求，都是只要客户端发起请求，服务接受到请求之后无论怎样都会立即响应客户端。如果有数据则返回数据，没有则返回空。那么长轮询则是指，如果客户端发起http请求(长轮询请求)，服务端收到请求之后，如果服务端有客户端所需要的数据则立即返回数据给客户端；反之如果服务端没有客户端需要的数据，则直接将这个客户端请求Hold住（不返回客户端，一直维持连接或者等到请求超时），等到有数据的时候，再使用这个Hold住的连接将数据返回给客户端。长轮询的核心就是：无数据就等待直到有数据。
长轮询的应用场景普遍都是在客户端需要不停的去服务端拉取数据的业务场景，如配置中心等。那么这种场景下为什么不使用定时拉取呢？因为定时拉取在大多数没有数据的时候都是无用的请求，这样会浪费网络资源，增加服务端的压力。且如果为了数据能够被实时拉取（有更新立即拉取），则需要将定时周期调的很短，从而增加服务压力。而长轮询的使用就可以完美的解决实时性和服务端性能的问题。因为没有数据的时候连接会Hold住，有数据可以返回给客户端，这就解决了实时性的问题。而其无需不断请求，所以大大降低了请求数，从而降低了服务端压力。
长轮询的实现是依赖长链接的。
2、长轮询的实现-Servlet 3.0
Servlet 3.0支持异步Http的异步请求，因此我们可以利用其功能实现长轮询。该方案需要特定的web容器如tomcat，性能上看不是最优方案，因此不做详细介绍。
3、长轮询的实现-Netty
说的高并发，海量链接，大家当然会想到大名鼎鼎的Netty。其就是对Nio的一个Java封装而已，但是其能够提供极好的性能，因此本方案选用Netty来实现Http的长轮询服务端。具体Netty如何实现Http服务器，这些Netty都有提供相应的编解码器来实现，具体的代码实现大家可以自行百度。
三、实现方案
具体的实现方案分为三个部分：应用集群节点实现、统一配置中心节点实现、配置修改实现。
1、应用集群节点实现
-
每个应用集群节点都需要获取到统一配置中心的所有服务器ip+port信息。具体可以通过配置的方式直接配置在每个应用集群节点中，也可以提供一个简单的三方http服务，仅仅返回统一配置中心服务器ip+port信息。
-
应用拿到所有配置服务节点信息后，随机选择一台（建议做下基本的负载均衡，如随机、自然轮询、权重轮询等）对其发起长轮询请求对应的配置即可（需携带配置的版本号）。
-
当长轮询请求返回（有数据返回或者超时返回）后，应用节点做对应的业务逻辑处理（如更新版本号，实现业务逻辑等），完成之后再次发起长轮询请求对应的配置信息。
2、统一配置中心节点实现
配置中心节点接收到长轮询配置请求之后，会根据版本号判断该配置是否有更新的配置数据（从数据库直接拉取数据即可，如果实际使用的过程中有性能问题，则可以考虑引入分布式缓存），如果有则直接返回最新的配置数据，如果没有则一直Hold住请求。
当有新的配置更新（配置更新之后，会通知所有的配置中心节点），且发现Hold住的链接中有对这个配置感兴趣的连接，则会拿出Hold的链接，并通过其返回最新的配置数据给客户端。
3、配置修改实现
配置修改客户端修改配置并持久化到数据库之后，需要通知所有的配置中心节点某个配置数据更新了。至于如何通知方法比较多：比如使用MQ的广播、使用Reids的事件通知、使用RPC调用依次请求各个节点等都可以。具体大家可以根据实际情况选择具体的实现。
四、方案的优缺点
1、优点
-
纯java代码实现，容易维护。
-
容易适配特有业务需求
-
没有第三方组件的学习维护成本
2、缺点
-
自己代码实现，开发成本高。
-
实现有一定的难度
五、惯例
如果你对本文有任何疑问或者高见，欢迎添加公众号共同交流探讨（添加公众号可以获得”Java高级架构“上10G的视频和图文资料哦）。