服务架构+分布式系统+dubbo+zookeeper

名字越长技术越强

已于 2022-12-06 09:48:46 修改

阅读量1k

点赞数

分类专栏： java学习文章标签： dubbo java-zookeeper zookeeper

于 2022-10-08 20:19:03 首次发布

本文链接：https://blog.csdn.net/gaxing4615/article/details/127197721

版权

java学习专栏收录该内容

27 篇文章 0 订阅

订阅专栏

什么是分布式系统

在《分布式系统原理与范型》一书中有定义：分布式系统是若干独立计算机的集合，这些计算机对用户来说就像单个系统；
分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多机器，处理更多的数据。
分布式系统是建立在网络之上的软件系统
首要需要明确的是，只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候，且硬件的提升（加内存、加磁盘、使用更好的cpu）高昂到得不偿失的时候，应用程序也不能进一步优化的时候，我们才需要考虑分布式系统。因为，分布式系统要解决的问题本身就是和单机系统一样的，而由于分布式多节点、通过网络通信的拓扑结构，会引入很多单机系统都没有的问题。为了解决这些问题又会引入更多的机制、协议，带来更多的问题。
在这里插入图片描述

单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。适用于小型网站，小型管理系统，将所有功能都部署到一个功能里，简单易用。
在这里插入图片描述

缺点：

1、性能扩展比较难

2、协同开发问题

3、不利于升级维护

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。
在这里插入图片描述

通过切分业务来实现各个模块独立部署，降低了维护和部署的难度，团队各司其职更易管理，性能扩展也更方便，更有针对性。

缺点：公用模块无法重复利用，开发性的浪费

分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。
在这里插入图片描述

流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)[ Service Oriented Architecture]是关键。
在这里插入图片描述

微服务架构

微服务是一种架构风格，一个大型的复杂软件应用，由一个或多个微服务组成。系统中各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。微服务就是一个轻量级的服务治理方案。对比SOA架构，使用注册中心代替ESB服务总线。注册中心相比服务总线来说，更加轻量级。
代表技术：SpringCloud、Dubbo等等
特点：系统是由多个服务构成，每个服务可以单独独立部署，每个服务之间是松耦合的，服务内部是高内聚的，外部低耦合的，高内聚就是每个服务只关注完成一个功能。低耦合就是服务之间没有直接关联
优点：
- 测试容易：服务高内聚低耦合，每个服务可以独立测试
- 可伸缩性强：服务相对独立，可随时增删服务实现系统服务变化，可针对某服务独立水平扩展
- 可靠性强：服务出现问题，受影响的位置是当前服务，不会影响其他服务。应用健壮性有更好的保证
- 跨语言程度更加灵活：可针对服务特性使用不同的语言开发，竟可能发挥出每种语言的特性
- 团队协作容易：团队专注自主研发的服务，对其他服务的了解可局限在服务的调用上
- 系统迭代容易：当服务发生变更时，只需要针对单一服务进行系统升级迭代
缺点
- 运维成本过高：部署数量较多，服务过多导致运维成本成倍提升
- 接口兼容多版本：因服务可独立升级迭代，所以导致接口版本过多
- 分布式系统的复杂性：系统分布，导致通讯成本提升，系统复杂度提升
- 分布式事务：分布式系统引起的分布式事务的出现，现在有很多的分布式事务解决方案，分布式事务不是不可解决的，这不会影响微服务架构的应用

微服务架构和分布式服务架构的区别

1. 含义不同
微服务架构：微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
分布式架构：分布式系统是若干独立计算机的集合，这些计算机对用户来说就像单个相关系统，即整个系统是由不同的计算机组成，而用户是无感知的，就像访问一台计算机一样。这里强调的是系统由不同物理上分离的计算机（服务器）组成。

2. 概念层面不同
微服务架构：微服务是设计层面的东西，一般考虑如何将系统从逻辑上进行拆分，也就是垂直拆分。微服务可以是分布式的，即可以将不同服务部署在不同计算机上，当然如果量小也可以部署在单机上。
分布式架构：分布式是部署层面的东西，即强调物理层面的组成，即系统的各子系统部署在不同计算机上。

3. 解决问题不同
微服务架构：微服务解决的是系统复杂度问题：一般来说是业务问题，即在一个系统中承担职责太多了，需要打散，便于理解和维护，进而提升系统的开发效率和运行效率，微服务一般来说是针对应用层面的。微服务如果用在其它系统，如存储系统感觉怪怪的，就像说Mysql集群是微服务的，总觉得哪里不舒服。
分布式架构：分布式解决的是系统性能问题：即解决系统部署上单点的问题，尽量让组成系统的子系统分散在不同的机器上进而提高系统的吞吐能力。

4. 部署方式不同
微服务架构：微服务的应用可以部署在是同一个服务器，不一定是分散在多个服务器上。微服务架构是一项在云中部署应用和服务的新技术。微服务架构是一种架构模式，它将一个复杂的大型应用程序划分成多个微服务，这些小型服务都在各自独立的进程中运行。
分布式架构：分布式是将一个大的系统划分为多个业务模块,这些业务模块会分别部署到不同的机器上，通过接口进行数据交互。

5. 耦合度不同
微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势，不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难。

拓展

分布式是否属于微服务？
答案是属于。微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。但是微服务不一定是分布式，因为微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。这也是分布式和微服务的一个细微差别。

什么是RPC

RPC【Remote Procedure Call】是指远程过程调用，是一种进程间通信方式，他是一种技术的思想，而不是规范。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。

也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。为什么要用RPC呢？就是无法在一个进程内，甚至一个计算机内通过本地调用的方式完成的需求，比如不同的系统间的通讯，甚至不同的组织间的通讯，由于计算能力需要横向扩展，需要在多台机器组成的集群上部署应用。RPC就是要像调用本地的函数一样去调远程函数；

RPC基本原理

在这里插入图片描述

RPC两个核心模块：通讯，序列化方便数据传输。
RPC框架：JAVA RMI、Dubbo、grpc

Dubbo

Dubbo是由阿里巴巴开源的一个高性能、基于Java开源的远程调用框架。正如许多的RPC系统中一样，Dubbo是基于定义服务的概念，指定通过参数和返回类型远程调用的方法。在服务端，服务端实现这个接口，并运行一个Dubbo服务器来处理客户端调用。在客户机有个存根。它提供与服务相同的方法。
官网：dubbo

Apache Dubbo |ˈdʌbəʊ| 是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：

面向接口的远程调用
智能容错和负载均衡
服务自动注册和发现

节点角色说明：
服务提供者（Provider）：暴露服务的服务提供方，服务提供者在启动时，向注册中心注册自己提供的服务。

服务消费者（Consumer）：调用远程服务的服务消费方，服务消费者在启动时，向注册中心订阅自己所需的服务，服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

注册中心（Registry）：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者

监控中心（Monitor）：服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心
服务容器（Container）：服务运行容器

调用关系说明

l 服务容器负责启动，加载，运行服务提供者。

l 服务提供者在启动时，向注册中心注册自己提供的服务。

l 服务消费者在启动时，向注册中心订阅自己所需的服务。

l 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

l 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

l 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

dubbo 常用标签

dubbo:application:指定应用程序名称
dubbo:registry:指定连接注册中心信息
dubbo:protocol:服务提供方注册服务采用的协议
dubbo:service:对外暴露服务配置
dubbo:reference:配置订阅的服务
其他标签去api查询

dubbo注册中心

Zookeeper（dubbo推荐使用）
Zookeeper 注册中心的基本使用和工作原理。
Nacos
Nacos 注册中心的基本使用和工作原理。
Multicast
Multicast 广播注册中心（限开发阶段使用）。
Redis
Redis 注册中心的基本使用和工作原理。

zookeeper

zookeeper是什么

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，主要为了解决分布式架构下数据一致性问题，典型的应用场景有分布式配置中心、分布式注册中心、分布式锁、分布式队列、集群选举、分布式屏障、发布/订阅等场景。

Dubbo官方推荐使用zookeeoer作为注册中心，注册中心负责服务地址的注册和查找，相当于目录服务。

什么是注册中心？举个简单的例子，就像字典目录，你要查个字，找到目录，然后找到对应的页，然后字就找到了。

zk也是一个意思，把你要注册的服务给到zk ，然后这台服务就注册到zk上了，当我们想通过zk找到一个服务的时候，zk把我们的请求指向这个对应的服务端上，你的请求就完美的过去了。

Zookeeper的3大特点：

Zookeeper至少具有以下特点：

1）可以用作分布式锁，可以用于集群管理，统一管理配置信息，负载均衡。

2）高可用性。一个Zookeeper服务通常由多台服务器节点构成，只要其中超过一半的节点存活，Zookeeper即可正常对外提供服务，所以Zookeeper具有高可用的特性。

3）高吞吐量特性，Zookeeper具有高吞吐量的特性，故而有很好的性能表现。

CAP原则：（面试）

CAP指的是：数据一致性（Consistency）、服务可用性（Availability）、分区容错性（Partition tolerance）。

- CAP原则指的是：在一个分布式系统中，这三个要素最多只能同时实现两点，不可能三者兼顾。

- 分布式系统中,必须要容忍网络的卡顿和延迟,所以分布式系统必须有个P（即，分区容错性）.

-  zookeeper保证的是CP, 即：数据一致性，分区容错性.
   eureka保证的是ap，即：服务可用性，分区容错性.

zookeeper保证CP，不保证A：

1）zookeeper保证的是CP:
zookeeper保证的是C，数据一致性；即，任何时刻对ZooKeeper的访问请求能得到一致的数据结果，

同时分布式系统中,一定可能会有网络的卡顿和延迟，即，P，分区容错性；

2）zookeeper不保证A,服务可用性；
zookeeper不能保证每次服务请求的可用性; 比如：在一些极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果。所以说，ZooKeeper不能保证服务可用性。

再比如，zookeeper在进行leader选举时，整个zookeeper集群都是不可用的。

当master主节点出现故障时，剩余的从节点们会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 而选举期间整个zookeeper集群都是不可用的，这就导致在选举期间，注册服务直接瘫痪；

所以说，ZooKeeper不能保证服务可用性。

注意，这里的服务可用性和zookeeper的高可用性是两码事；

Zookeeper的高吞吐量特性：

Zookeeper具有高吞吐特性的主要原因有以下几点:

Zookeeper集群的任意一个服务端节点都可以直接响应读请求(写请求会不一样些)，并且可以通过增加服务器节点进行横向扩展。这是其吞吐量高的主要原因。

Zookeeper将全部数据存储于内存中，从内存中读取数据，不需要进行磁盘IO，所以速度非常快。

Zookeeper的写请求，或者说事务请求，因为要进行不同服务器节点之间状态的同步，所以在一定程度上会影响其吞吐量。故而简单的增加Zookeeper的服务器节点数量,并不一定能够提升Zookeeper的吞吐量。服务器节点增加，有利于提升读请求的吞吐量，但会延长节点间数据同步的时间。

Zookeeper的架构：

Zookeeper非常类似于一个文件系统，它的每个节点都叫数据节点（znode），znode节点上可以存储数据，也可以再产生多个子节点。

Zookeeper的节点不能称为目录或者文件，要叫做znode节点，既可以存储数据又可以产生子节点。

znode节点的4种类型 :（面试）

znode分为四种节点

1、持久节点.
持久节点，是最常见的Znode类节点，一旦创建将一直存在于Zookeeper中，即便服务器断开连接、zookeeper重启等，持久节点还是存在着的。除非通过删除操作进行删除，否则会永久的保存在zookeeper中。

2、持久有序节点.
只要客户端(即其他的服务模块)存储数据，会永久的保存在zookeeper中，并且会在zookeeper中生成一个唯一并且有序的节点，先进来的节点值较小。

3、临时节点.
当客户端断开连接后，会自动删除节点信息。

4、临时有序节点.
只要客户端(即其他的服务模块)存储数据，会生成一个唯一并且有序的节点，先进来的节点值较小。

当客户端断开连接后，自动删除该节点。

Zookeeper的监控机制.

可以有多个客户端(即其他的服务模块)监听zookeeper的某一个znode节点.

每当被监听的节点，发生了增删改等操作之后，zookeeper就会通知给监听当前节点的所有客户端。

Zookeeper的（节点的）工作流程.

leader节点.(领导)
leader节点管理着整个zookeeper集群中的全部节点，leader节点主要负责写操作、和数据同步操作。
leader节点的写操作：
在Zookeeper中，只有leader节点可以进行写操作；
为了保证数据的同步，当leader节点进行写操作时，会对外广播（我这边变动了数据，你们那边也同步一下），当从节点们接收到广播后，会开始持久化新的数据到本地（此时还没有commit）;
从节点持久化完成后，会给leader一个反馈; 当超过半数以上的从节点持久化完成后，leader节点会再次广播，通知从节点们开始commit。
最后，从节点都同步数据完毕，leader才算完成了一次写操作。
所以Zookeeper有一个特点：如果有超过半数的从节点持久化数据失败，那么此次写操作也宣布失败，所有的持久化的从节点全部回滚。
follower.(追随者)
follower指的是追随leader的从节点，主要负责读操作。
follower从节点当接收到写操作的请求后，会第一时间将这个写操作请求呈交给leader主节点处理。
当leader主节点突然挂掉时，follower从节点们会发起投票选举，选举出新的leader。
observer. (观察者)
observer观察者节点和 follower从节点几乎一样，也是追随leader，主要负责读操作;
也是当接收到写操作的请求后,会第一时间将这个写操作呈交给leader主节点处理.
不同的是：当leader主节点挂掉时，observer节点不会参与投票选举，它只会等待一个新的leader出现后，直接去追随新的leader。
looking. （选举者）
如果leader已经存在，这个新节点会直接变为follower从节点，追随当前的leader节点.
如果leader不存在，该looking节点会直接发起一次选举leader的投票，直到leader选出来后，该节点再由looking变成follower从节点，去追随leader主节点。

zookeeper如何保证存储数据的有序性？(也是选举leader的关键点)

zookeeper为了保证数据的有序性，会给每一个写操作的数据，编写一个全局唯一的zxid.
zxid是一个64位的数字：前32位会是由当前节点参与的选举次数决定，后32位是存储数据的全局唯一id。
因为先生成的节点值较小、后生成的节点值较大的特点，故而后存储的数据的zxid 一定大于先存储的数据的zxid。
拓展：zookeeper在执行写操作时，是不会阻塞IO的，每次收到写操作的请求后，leader主节点会先把这个请求放到一个队列中，然后挨个的进行处理。

Zookeeper选举机制的两个要素：

答：zxid和myid;
哪个节点的zxid越大，说明数据越新越全，则会被选举为leader

zxid：
        zookeeper为了保证数据的有序性，会给每一个写操作的数据，编写一个全局唯一的zxid.
        zxid是一个64位的数字：前32位会是由当前节点参与的选举次数决定，后32位是存储数据的全局唯一id。
        因为先生成的节点值较小、后生成的节点值较大的特点，故而 后存储的数据的zxid 一定大于 先存储的数据的zxid。
myid:
        myid的值是zoo.cfg文件里定义的server.A项A的值，Zookeeper 启动时会读取这个文件，拿到里面的数据与 zoo.cfg 里面的配置信息，比较从而判断到底是那个server，只是一个标识作用。

三个核心选举原则：

zookeeper集群中只有超过了半数以上的服务器启动，此集群才能正常工作；
在集群正常工作之前，myid小的服务器会给myid大的服务器投票，这种投票会一直持续到集群开始正常工作，即，选出了leader。
选出leader之后，之前的服务器节点的状态要由looking转为following从节点，以后的服务器不管是不是新加进来的都会变成follower从节点。

zookeeper下载、启动（单节点）

zookeeper集群（补充在文章最后）

去官网下载即可

zookeeper 单点故障

单节点的zookeeper是使用出现异常导致宕机，造成：

无法发现新服务
之前的服务仍可正常使用（消费者会拉取注册中心的服务缓存到本地，即使注册中心宕机，之前的服务也可用）

zookeeper 集群

补充文章最后

启动报错–缺少zoo.cfg文件

启动zkServer.cmd(windows)时闪退，无法看到报错信息，打开此命令脚本在尾端加入 pause 。在次启动不会闪退看到错误信息无zoo.cfg文文件。
解决：将conf下的zoo_sample.cfg复制、重命名
在这里插入图片描述

启动成功

在这里插入图片描述
服务端启动成功后若无法识别是否启动成功，可以打开客户端去看。

dubbo-admin 可视化监控

下载

https://gitee.com/kabuka/dubbo

启动

dubbo-admin 进行 install 后 war包在Tomcat中启动
用户名、密码：root\root
在这里插入图片描述

访问

http://localhost:8080/dubbo-admin-2.5.8

检测到的服务

在这里插入图片描述

dubbo、zookeeper依赖

dubbo-dependencies-zookeeper 将自动为应用增加 Zookeeper 相关客户端的依赖，减少用户使用 Zookeeper 成本，如使用中遇到版本兼容问题，用户也可以不使用 dubbo-dependencies-zookeeper，而是自行添加 Curator、Zookeeper Client 等依赖。

由于 Dubbo 使用 Curator 作为与 Zookeeper Server 交互的编程客户端，因此，要特别注意 Zookeeper Server 与 Dubbo 版本依赖的兼容性
请添加图片描述

dubbo环境搭建

依赖

   <!-- dubbo -->
        <dependency>
            <groupId>org.apache.dubbo</groupId>
            <artifactId>dubbo-spring-boot-starter</artifactId>
            <version>2.7.3</version>
        </dependency>
        <!-- zookeeper -->
        <dependency>
            <groupId>com.github.sgroschupf</groupId>
            <artifactId>zkclient</artifactId>
            <version>0.1</version>
        </dependency>

        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-framework</artifactId>
            <version>2.12.0</version>
        </dependency>
        <dependency>
            <groupId>org.apache.curator</groupId>
            <artifactId>curator-recipes</artifactId>
            <version>2.12.0</version>
        </dependency>

        <dependency>
            <groupId>org.apache.zookeeper</groupId>
            <artifactId>zookeeper</artifactId>
            <version>3.4.14</version>
            <!--排除这个slf4j-log4j12-->
            <exclusions>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-log4j12</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

提供者

service

@Service // dubbo所提供的servcie

package com.xusx.provider.service.impl;

import com.xusx.provider.service.TickerServce;
import org.apache.dubbo.config.annotation.Service;
import org.springframework.stereotype.Component;

@Service  //可以被扫描到，在项目启动就自动注册到注册中心，一定要注意，这个是dubbo包里的
@Component  //这里不使用@Service是为了方便区分dubbo和spring包下的@Service
public class TicketServiceImpl implements TickerServce {
    @Override
    public void sell() {
        System.out.println("提供者--sell被调用");
    }
}

application.yml

server.port=8082

# 注册的服务名称
dubbo.application.name=provider-server
# 注册中心地址
dubbo.registry.address=zookeeper://127.0.0.1:2181
# 扫描要注册的服务
dubbo.scan.base-packages=com.xusx.provider.service

消费者

在本项目定义一个同提供者服务相同路径的dubbo接口
在这里插入图片描述

package com.xusx.consumer.service;

import com.xusx.provider.service.TickerServce;
import org.apache.dubbo.config.annotation.Reference;
import org.springframework.stereotype.Service;

@Service
public class UserService {

                     // 1、引用,Pom坐标；2、可以定义路径相同的接口
@Reference  // 使用2：在本项目定义一个同提供者服务相同路径的bubbo接口
TickerServce tickerServce;

public void getTicket(){
    tickerServce.sell();
    System.out.println("消费者成功调用了-----");
}

}

测试

在这里插入图片描述

zookeeper集群搭建（伪集群）

解压-创建3份
zookeeper-3.4.13.tar.gz

taz -zxf zookeeper-3.4.13.tar.gz

在这里插入图片描述

创建myid文件
创建⼀个 myid ⽂件，内容分别是1、2、3 。这个⽂件就是记录每个服务器的ID
每一个zk都有对应的myid文件
配置文件： mv zoo_sample.cfg----> zoo.cfg
- 修改端口
- 指定dataDir文件路径（下面放置myid文件）
- 配置集群列表
  server.服务器ID=服务器IP地址：服务器之间通信端⼝：服务器之间投票选举端⼝
  伪集群：通信端口和集群端口各不相同，否则会出现address already is used
  真集群：通信端口和集群端口相同

# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial 
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between 
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just 
# example sakes.
dataDir=/usr/zookeeper-cluster/zookeeper-cluster03/tmp
# the port at which the clients will connect
clientPort=21833
# the maximum number of client connections.
# increase this if you need to handle more clients
#maxClientCnxns=60
#
# Be sure to read the maintenance section of the 
# administrator guide before turning on autopurge.
#
# http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
#
# The number of snapshots to retain in dataDir
#autopurge.snapRetainCount=3
# Purge task interval in hours
# Set to "0" to disable auto purge feature
#autopurge.purgeInterval=1
server.1=192.168.79.128:2881:3881
server.2=192.168.79.128:2882:3882
server.3=192.168.79.128:2883:3883