zk主机管理系统（asp，oledb链接access）

本文目录

• asp，oledb链接access
• 我的电脑开机后，要等很久后屏幕才开始显示东西！
• 7、zk典型应用场景之分布式锁
• 对zookeeper设置ACL属性
• ZKEpos食堂消费机怎样连接电脑
• Zookeeper 理论基础
• kafkak配置仅允许受信任的JNDI连接如何配置

asp，oledb链接access

Dim MM_Conn_STRING,DatabasePath
DatabasePath="../db/***.mdb" ’数据库路径
MM_Conn_STRING = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Server.MapPath("" & DatabasePath &"")
’Provider=Microsoft.Jet.OLEDB.4.0;Data Source=E:\WebFolder\Ebay100\databases\data_center_Creater.mdb
set conn=server.CreateObject("adodb.connection")
conn.open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Server.MapPath("" & DatabasePath &"")
----------------------------
以上是我用的方法，从代码中看出，并非“应该用绝对路径”，实际上是因为你的数据库位置表示不明确所致。如果你的页面文件（index.asp）和你的数据库在同一文件夹下，则：
DatabasePath="my_site.mdb"
即可。你再试试。

我的电脑开机后，要等很久后屏幕才开始显示东西！

解决电脑启动速度太慢,快速启动你的电脑
一、BIOS的优化设置
在BIOS设置的首页我们进入“Advanced BIOS Features”选项，将光标移到“Frist Boot Device”选项，按“PageUP”和“PageDOWN”进行选择，默认值为“Floppy”，这表示启动时系统会先从软驱里读取启动信息，这样做会加长机器的启动时间，减短软驱的寿命。所以我们要选“HDD-0”直接从硬盘启动，这样启动就快上好几秒。 另外，对于BIOS设置中的“Above 1MbMemoryTest”建议选“Disabled”，对于“QuickPowerOnSelftest”建议选择Enabled。
在“Advanced Chipset Features”项中的设置对机子的加速影响非常大，请大家多加留意。将“Bank 0/1 DRAM Timing”从“8ns/10ns”改为“Fast”或“Turbo”。“Turbo”比“Fast”快，但不太稳定，建议选“Fast”。如果内存质量好可以选“Turbo”试试，不稳定可以改回“Fast”。
对于内存品质好的内存条建议在“SDRAM CAS Latency”选项中设置为“2”，这样可以加快速度哦。
较新的主板都支持AGP4X，如果你的显卡也支持AGP4X，那么就在“AGP-4XMode”处将这项激活，即选为“Enabled”，这才会更好的发挥显卡的能力，加快系统启动速度。
二、启动DMA方式，提高硬盘速度
采用UDMA/33、66、100技术的硬盘最高传输速率是33MB/s、66MB/s、100MB/s，从理论上来说是IDE硬盘（这里是指PIO MODE4 模式，其传输率是16.6MB/s）传输速率的3～6倍，但是在Windows里面缺省设置中，DMA却是被禁用的，所以我们必须将它打开。
具体方法是：打开“控制面板→系统→设备管理器”窗口，展开“磁盘驱动器”分支，双击UDMA硬盘的图标，进入“属性→设置→选项”，在“DMA”项前面“√”，然后按确定，关闭所有对话框，重启电脑即可。
三、去掉Windows的开机标志。
首先你要打开“开始”→“设置”→“文件夹选项”，从“查看”标签里的“高级设置”列表框中勾选“显示所有文件”。然后打开C盘，找到MSdos.sys这个文件，并取消它的“只读”属性，打开它，在“Option”段落下，加上一行语句：LOGO=0，这样Windows的开机图案就不会被加载运行，开机时间也可以缩短3秒钟。
四、优化“启动”组。
电脑初学者都爱试用各种软件，用不多久又将其删除，但常常会因为某些莫名其妙的原因，这些软件还会驻留在“启动”项目中（尤其是在使用一些D版软件时），Windows启动时就会为此白白浪费许多时间。要解决这个问题，其实很简单，你可以打开“开始”→“运行”，在出现的对话框的“打开”栏中选中输入“msconfig”，然后点击“确定”，就会调出“系统配置实用程序”，点击其中的“启动”标签，将不用载入启动组的程序前面的“√”去掉就可以了。如此一来，至少可以将启动时间缩短10秒。
五、整理、优化注册表。
Windows在开机启动后，系统要读取注册表里的相关资料并暂存于RAM（内存）中，Windows开机的大部分时间，都花费了在这上面。因此，整理、优化注册表显得十分必要。有关注册表的优化，可以使用Windows优化大师等软件。以Windows优化大师，点击“注册信息清理”→“扫描”，软件就会自动替你清扫注册表中的垃圾，在扫描结束后，会弹出个菜单让你选择是否备份注册表，建议选择备份，备份后再点击“清除”即可。
六、经常维护系统。
如果在系统中安装了太多的游戏、太多的应用软件、太多的旧资料，会让你的电脑运行速度越来越慢，而开机时间也越来越长。因此，最好每隔一段时间，对电脑做一次全面的维护。点击“开始”→“程序”→“附件”→“系统工具”→“维护向导”，然后点击“确定”按钮即可对电脑进行一次全面的维护，这样会使你的电脑保持在最佳状态。对于硬盘最好能每隔2个星期就做一次“磁盘碎片整理”，那样会明显加快程序启动速度的，点击“系统工具”→“磁盘碎片整理程序”即可。注意在整理磁盘碎片时系统所在的盘一定要整理，这样才能真正加快Windows的启动顺序。
七、扩大虚拟内存容量。
如果你的硬盘够大，那就请你打开”控制面板“中的“系统”，在“性能”选项中打开“虚拟内存”，选择第二项：用户自己设定虚拟内存设置，指向一个较少用的硬盘，并把最大值和最小值都设定为一个固定值，大小为物理内存的2倍左右。这样，虚拟存储器在使用硬盘时，就不用迁就其忽大忽小的差别，而将固定的空间作为虚拟内存，加快存取速度。虚拟内存的设置最好在“磁盘碎片整理”之后进行，这样虚拟内存就分不在一个连续的、无碎片文件的空间上，可以更好的发挥作用。
八、去掉“墙纸”、“屏幕保护”等花哨的设置。
这些设置占用系统资源不说，还严重影响Windows的启动顺序。去掉它们的方法是：在桌面空白处点击鼠标右键，在弹出的菜单中选择“属性”，在弹出的对话框中分别选择“背景”和“屏幕保护程序”标签，将“墙纸”和“屏幕保护程序”设置为“无”即可。
九、删除Autoexec.bat和Config.sys。
系统安装盘根目录下的Autoexec.bat和Config.sys这两个文件，Windows已经不需要它们了，可以将它们安全删除，这样可以加快Windows的启动速度。
十、精简*.ini文件，尤其是System.ini和Win.ini的内容。
在system.ini的字段的shell=Explorer.exe是木马喜欢的隐蔽加载之所，木马们通常会将该句变为这样：shell=Explorer.exe file.exe，注意这里的file.exe就是木马服务端程序！有了木马随后加载运行不仅对系统安全造成了威胁，电脑启动也慢了许多；对Win.ini中的“Run”及“Load”后面加载的、不是每次开机必须运行的程序，可以暂时清除，等以后要用时再点击运行。这样开机时Windows调用的相关文件就会减少许多，启动速度自然就会快多了。
十一、关闭磁盘扫描。
用文本器打开msdos.sys，会看到以下内容：

bootmulti=1
bootgui=1
autoscan=1
如果不想非正常关机后运行磁盘扫描程序，可以把atuoscan=1改为autoscan=0，这样在非正常关机后计算机的启动速度也会快上一些（因为scandisk没有运行嘛）。
十二、让引导信息停留时间最短。
用文本器打开msdos.sys，设置中的BootDelay为0即可。
十三、减少不必要的字体文件。
字体文件占用系统资源多，引导时很慢，并且占用硬盘空间也不少。因此尽量减少不必要的字体文件。但如果删错了字体文件，搞不好会使Windows不正常。因此可以采用下面这个“偷梁换柱”的方法（可以实现字体文件的安装，而不占用大量的磁盘空间）：首先打开字库文件夹（如F:\\zk），选中全部TrueType字体文件，用鼠标的右键将它们拖动到C:\\Windows\\Fonts文件夹中，在弹出的菜单中选择“在当前位置创建快捷方式”，这样就可以在系统的字体文件夹下建立字库文件的快捷方式了。当需要使用这些字库文件时，只要插入字库光盘，不用时取出就可以了。
十四、删去多余的Dll文件。在Window*作系统的System子目录里有许多的Dll文件，这些文件可能被许多文件共享，但有的却没有没有一个文件要使用它，也就是说这些文件没用了，为了不占用硬盘空间和提高启动运行速度，完全可以将其删除。
十五、“旁门左道”的办法。如采用系统悬挂，即将当前系统状态在关机后保存，下次开机后，系统会直接进入上次关机前的桌面，用这种方法，开机时间最快可以达到4-5秒钟，但不是所有的主板BIOS都支持的，设置起来也稍显麻烦。
打开注册表，展开到HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\SharedDlls子键，在右边的有许多Dll文件，如果数据为0，则可以判定该Dll文件没有程序共享，可以删掉它。

7、zk典型应用场景之分布式锁

分布式锁： 分布式锁是控制分布式系统之间同步访问共享资源的一种方式，如果不同的系统化或者同一个系统的不同主机之间共享一个或者一组资源，那么在访问这些资源的时候，往往需要通过一些互斥手段防止彼此之间的干扰，以保证一致性，这种情况就需要使用分布式锁。

排他锁： 核心是如何保证当前有且仅有一个事务获取到锁，并且锁释放之后，所有正在等待获取锁的事务都能够被通知到。
定义和获取锁： 在zk中，通过一个数据节点来表示一个锁（因为在zk中数据节点是唯一的），zk会保证在所有客户端中，最终只有一个客户端能够创建一个节点成功，最终只有一个客户端能够创建成功，那么久可以认为这个客户端获得了锁。同时没有获取到锁的客户端就需要到相应节点上注册一个子节点变更的watcher监听，以便实时的监听lock节点的变更情况。
释放锁： 由于定义锁的节点是一个临时节点，因此存在两种情况释放锁1、当前获取锁的客户端机器发生宕机了。zk就会把该临时节点删除2、正常执行完业务逻辑，客户端会主动将自己创建的临时节点删除。而无论什么情况下面删除了节点，zk都会通知所有在该节点上注册了子节点变更watcher将的客户端。这些客户端在接收到通知后，会再次重新发起分布式锁获取，即重复“获取锁过程”。
（获取锁和释放锁流程）

共享锁： 称读锁。如果事务T对数据对象O加了共享锁，那么当前的事务只能对O进行读取操作，其他事务也只能对这个数据对象加共享锁-直到该数据对象上的所有共享锁都被释放。
定义锁： 同样是使用zk上的数据节点来表示一个锁，是一个类似“/share_lock/-请求类型-序号”的临时顺序节点。
获取锁： 在需要获取共享锁时候，所有客户端都会到/share_lock这个节点下面创建一个临时顺序节点，如果当前是读请求，那么就是例如/share_lock/192.168.0.1-R-0000000001的节点；如果是写请求，那么就会创建例如/share_lock/192.168.0.1-W-0000000001的节点。
判断读写顺序： 不同事务都可以同时对一个数据对象进行读写操作，而更新操作必须在当前没有任何事务进行读写操作的情况下面进行。基于这个原则可以通过下面四个步骤来确定分布式读写顺序：

释放锁： 和排他锁一样。

加锁情况：

（1）实现流程

（2）源码解读

1、InterProcessMutex构造函数

2、加锁

InterProcessMutex.class

3、锁的可重入性

4、抢夺锁

参考资料：
《从Paxos到Zookeeper 分布式一致性原理与实践》》
***隐藏网址***
***隐藏网址***

对zookeeper设置ACL属性

对zookeeper设置ACL属性

我们以zkCli为例，来说明zookeeper对ACL的设置。

使用zkCli时，ACL的格式由《schema》:《id》:《acl》三段组成。

注意：zookeeper对权限的控制是znode级别的，不具有继承性，即子节点不继承父节点的权限。这种设计在使用上还是有缺陷的，因为很多场景下，我们还是会把相关资源组织一下，放在同一个路径下面，这样就会有对一个路径统一授权的需求。

这是默认方式，表示没有认证。当创建一个新的节点(znode)，而又没有设置任何权限时，就是这个值，例如：

看到/noacl的ACL属于就是world schema的，因为它没有设置ACL属性，这样任何人都可以访问这个节点。

如果要手工设置这个属性，那么此时的id域只允许一个值，即anyone，格式如下：

这种授权不针对任何特点ID，而是对所有已经添加认证的用户，换句话说，就是对所有已经通过认证的用户授权。

用法如下：

注意:

举例：

这个例子中，我们先添加了三个认证用户tom1,tom2,tom3，然后通过setAcl设置ACL，命令中指定了id为tom2，根据前面的说法，这个id值是被忽略的，写任何值，甚至空值也得到一样的结果。我们看到最后getAcl查询出来的结果包含所有前面添加的三个认证用户。

补充说明：zkCli的命令 addauth digest user:pwd 是用来添加当前上下文中的认证用户的：

其实我不是很理解这个功能，难道在一个会话(session)里可以添加多个认证用户吗，那验证的时候按哪一个算呢；如果不同的用户有不同的授权会导致授权冲突吗？以谁为准？

几点总结：

所以这种授权方式更倾向于用作测试开发环境，而不是产品环境中。

这就是最普通的用户名:密码的验证方式，在一般业务系统中最常用。
格式如下：

和schema auth相比，有两点不同：

密码可以通过如下shell的方式生成：

例如：

或者可以使用zookeeper的库文件生成：

输出的 root:jalRr+knv/6L2uXdenC93dEDNuE= 就是传递给setAcl使用的id串。

注意，只有通过zkCli.sh设置digest的ACL时id才需要密文，而通过zookeeper的客户端设置digest的ACL时对应的auth数据是明文。这个属于编码实现的问题了。

和auth比较，digest有如下特性：

就是客户机地址，或者是主机名、或者是IP地址。
主机名可以是单个主机名，也可以是域名。IP可以是单个IP地址，也可以是IP地址段，比如ip:192.168.1.0/16。
这个不细说了，比较简单，也没有验证过。

设置一个超级用户，这个超级用户的设置必须在zookeeper内部，zookeeper启动之前设置好。在这种scheme情况下，超级用户具有超级权限，可以做任何事情(cdrwa)，不需要授权。

5.1 设置zookeeper环境变量SERVER_JVMFLAGS：

5.2 重启zookeeper

创建/test节点，并且设置acl为jerry1用户。

5.3 添加认证用户tom

5.4 访问节点/test

这时失败，因为tom用户没有权限。

5.3 添加认证用户root

5.4 再次访问节点/test

成功，虽然root也没有在/test的acl列表里面(是有jerry1)，但是也能访问，因为root在zookeeper集群里面被配置成了超级用户。

ZKEpos食堂消费机怎样连接电脑

要用网线连接。
食堂消费机牵网线到电脑主机上。食堂饭卡一卡通的牵网线的主要作用是可以实现数据的实时传输。饭卡机消费的数据可以通过网线传输到软件里面。通过软件查看消费数据
如果用户第一次进入消费管理系统，系统会提示创建数据库，只有建立了数据库，IC 消费管理系统才能使用。用户进入管理系统时，系统会自动弹出一个登陆窗口，系统默认的用户名是“Admin”，系统默认的密码是“8”，用户在“用户名”和“密码”框中输入相应的帐号和密码后单击“登录”按钮后用户就可以进入系统。进入管理系统打开开卡就可以对卡片进行充值/减值操作
注意事项
请谨慎执行该操作，系统初始化将对系统还原为出厂状态，系统中所有的

Zookeeper 理论基础

ZooKeeper 由雅虎研究院开发，后来捐赠给了 Apache。ZooKeeper 是一个开源的分布式应用程序协调服务器，其为分布式系统提供一致性服务。其一致性是通过基于 Paxos 算法的ZAB 协议完成的。其主要功能包括：配置维护、域名服务、分布式同步、集群管理等。
***隐藏网址***

zk 是如何保证分布式系统的一致性的呢？是因为 zk 具有以下几方面的特点：

对于zk 理论的学习，最重要也是最难的知识点就是 Paxos 算法。所以我们首先学习 Paxos算法。

Paxos 算法是莱斯利·兰伯特(Leslie Lamport)1990 年提出的一种基于消息传递的、具有高容错性的一致性算法。Google Chubby 的作者 Mike Burrows 说过，世上只有一种一致性算法， 那就是 Paxos，所有其他一致性算法都是 Paxos 算法的不完整版。Paxos 算法是一种公认的晦涩难懂的算法，并且工程实现上也具有很大难度。较有名的 Paxos 工程实现有Google Chubby、ZAB、微信的 PhxPaxos 等。
Paxos 算法是用于解决什么问题的呢？Paxos 算法要解决的问题是，在分布式系统中如何就某个决议达成一致。

拜占庭将军问题是由 Paxos 算法作者莱斯利·兰伯特提出的点对点通信中的基本问题。该问题要说明的含义是，在不可靠信道上试图通过消息传递的方式达到一致性是不可能的。所以，Paxos 算法的前提是不存在拜占庭将军问题，即信道是安全的、可靠的，集群节点间传递的消息是不会被篡改的。

一般情况下，分布式系统中各个节点间采用两种通讯模型：共享内存（Shared Memory）、消息传递（Messages Passing）。而 Paxos 是基于消息传递通讯模型的。

在 Paxos 算法中有三种角色，分别具有三种不同的行为。但很多时候，一个进程可能同时充当着多种角色。

Paxos 算法的一致性主要体现在以下几点：

Paxos 对于提案的提交算法有两种方案，2PC 与 3PC。

它们的区别主要就在于 accept 阶段中是否包含 commit 功能。具体看下面的描述。

Paxos 算法的 3PC 执行过程划分为三个阶段：准备阶段 prepare、接受阶段 accept，与提交阶段 commit。

若提案者接收到的反馈数量超过了半数，则其会向外广播两类信息：

2PC 与 3PC 的区别是，在提案者接收到超过半数的表决者对于 parepare 阶段的反馈后，其会向所有表决者发送真正的提案 proposal。当表决者接受到 proposal 后就直接将其同步到了本地，不用再等待 commit 消息了。

那么，为什么不直接使用 2PC，而要使用 3PC 呢？是因为 2PC 中存在着较多的弊端（这里就不再展开来说了）。所以很多 Paxos 工业实现使用的都是 3PC 提交。但 2PC 提交的效率要高于 3PC 提交，所以在保证不出问题的情况下，是可以使用 2PC 提交的。

前面所述的Paxos 算法在实际工程应用过程中，根据不同的实际需求存在诸多不便之处， 所以也就出现了很多对于基本 Paxos 算法的优化算法，以对 Paxos 算法进行改进，例如，Multi Paxos、Fast Paxos、EPaxos。

例如，Paxos 算法存在“活锁问题”，Fast Paxos 算法对 Paxos 算法进行了改进：只允许一个进程提交提案，即该进程具有对 N 的唯一操作权。该方式解决了“活锁”问题。

ZAB ，Zookeeper Atomic Broadcast，zk 原子消息广播协议，是专为 ZooKeeper 设计的一种支持崩溃恢复的原子广播协议，在 Zookeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性。

Zookeeper 使用一个单一主进程来接收并处理客户端的所有事务请求，即写请求。当服务器数据的状态发生变更后，集群采用 ZAB 原子广播协议，以事务提案 Proposal 的形式广播到所有的副本进程上。ZAB 协议能够保证一个全局的变更序列，即可以为每一个事务分配一个全局的递增编号 xid。

当 Zookeeper 客户端连接到 Zookeeper 集群的一个节点后，若客户端提交的是读请求， 那么当前节点就直接根据自己保存的数据对其进行响应；如果是写请求且当前节点不是Leader，那么节点就会将该写请求转发给 Leader，Leader 会以提案的方式广播该写操作，只要有超过半数节点同意该写操作，则该写操作请求就会被提交。然后 Leader 会再次广播给所有订阅者，即 Learner，通知它们同步数据。

ZAB 协议是 Paxos 算法的一种工业实现算法。但两者的设计目标不太一样。ZAB 协议主要用于构建一个高可用的分布式数据主从系统，即 Follower 是 Leader 的从机，Leader 挂了， 马上就可以选举出一个新的 Leader，但平时它们都对外提供服务。而 Fast Paxos 算法则是用于构建一个分布式一致性状态机系统，确保系统中各个节点的状态都是一致的。

另外，ZAB 还使用 Google 的 Chubby 算法作为分布式锁的实现，而 Google 的 Chubby 也是 Paxos 算法的应用。

zk 集群对于事务请求的处理是 Fast Paxos 算法的体现，即只允许 Leader 提出提案。其属于 3PC 提交。

但 Leader 选举是 Paxos 算法的体现，因为 Leader 宕机后，所有 Follower 均可提交提案， 它们在最初都是“我选我”。其属于 2PC 提交。

为了避免 Zookeeper 的单点问题，zk 也是以集群的形式出现的。zk 集群中的角色主要有以下三类：

Learner：学习者，同步者。
Learner = Follower + Observer
QuorumPeer = Participant = Leader + Follower

在 ZAB 中有三个很重要的数据：

ZAB 协议中对zkServer 的状态描述有三种模式。这三种模式并没有十分明显的界线，它们相互交织在一起。

zk 集群中的每一台主机，在不同的阶段会处于不同的状态。每一台主机具有四种状态。

在集群启动过程中，或 Leader 宕机后，集群就进入了恢复模式。恢复模式中最重要的阶段就是 Leader 选举。

A、serverId
这是zk 集群中服务器的唯一标识，也称为 sid，其实质就是 zk 中配置的 myid。例如， 有三个 zk 服务器，那么编号分别是 1,2,3。
B、 逻辑时钟
逻辑时钟，Logicalclock，是一个整型数，该概念在选举时称为 logicalclock，而在选举结束后称为epoch。即 epoch 与 logicalclock 是同一个值，在不同情况下的不同名称。

在集群启动过程中的 Leader 选举过程（算法）与 Leader 断连后的 Leader 选举过程稍微有一些区别，基本相同。

A、集群启动中的 Leader 选举

对于 Server1 而言，它的投票是(1, 0)，接收 Server2 的投票为(2, 0)。其首先会比较两者的 ZXID，均为 0，再比较 myid，此时 Server2 的 myid 最大，于是 Server1 更新自己的投票为(2, 0)，然后重新投票。对于 Server2 而言，其无须更新自己的投票，只是再次向集群中所有主机发出上一次投票信息即可。
(4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息。对于 Server1、Server2 而言，都统计出集群中已经有两台主机接受了(2, 0)的投票信息，此时便认为已经选出了新的 Leader，即 Server2。
(5) 改变服务器状态。一旦确定了 Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为 FOLLOWING，如果是 Leader，就变更为 LEADING。
(6) 添加主机。在新的 Leader 选举出来后 Server3 启动，其想发出新一轮的选举。但由于当前集群中各个主机的状态并不是 LOOKING，而是各司其职的正常服务，所以其只能是以Follower 的身份加入到集群中。

B、 宕机后的 Leader 选举
在 Zookeeper 运行期间，Leader 与非 Leader 服务器各司其职，即便当有非 Leader 服务器宕机或新加入时也不会影响 Leader。但是若 Leader 服务器挂了，那么整个集群将暂停对外服务，进入新一轮的 Leader 选举，其过程和启动时期的 Leader 选举过程基本一致。

前面我们说过，恢复模式具有两个阶段：Leader 选举与初始化同步。当完成 Leader 选举后，此时的 Leader 还是一个准 Leader，其要经过初始化同步后才能变为真正的 Leader。

具体过程如下：

当集群中的 Learner 完成了初始化状态同步，那么整个 zk 集群就进入到了正常工作模式了。
如果集群中的 Learner 节点收到客户端的事务请求，那么这些 Learner 会将请求转发给Leader 服务器。然后再执行如下的具体过程：

Observer 数量并不是越多越好，一般与 Follower 数量相同。因为 Observer 数量的增多虽不会增加事务操作压力，但其需要从 Leader 同步数据，Observer 同步数据的时间是小于等于 Follower 同步数据的时间的。当 Follower 同步数据完成，Leader 的 Observer 列表中的Observer 主机将结束同步。那些完成同步的 Observer 将会进入到另一个对外提供服务的列表。那么，那些没有同步了数据无法提供服务的 Observer 主机就形成了资源浪费。
所以，对于事务操作发生频繁的系统，不建议使用过多的 Observer。

Leader 中保存的 Observer 列表其实有两个：
all：包含所有 Observer。
service：已经完成了从 Leader 同步数据的任务。service 《= all。其是动态的。

Leader 中保存的 Follower 列表其实也有两个：
all：要求其中必须有过半的 Follower 向Leader 反馈ACK
service：

当集群正在启动过程中，或 Leader 崩溃后，集群就进入了恢复模式。对于要恢复的数据状态需要遵循三个原则。

若集群中 Leader 收到的 Follower 心跳数量没有过半，此时 Leader 会自认为自己与集群的连接已经出现了问题，其会主动修改自己的状态为 LOOKING，去查找新的 Leader。
而其它 Server 由于有过半的主机认为已经丢失了 Leader，所以它们会发起新的 Leader选举，选出一个新的 Leader。

正常情况下，当 Leader 收到超过半数 Follower 的 ACKs 后，就向各个 Follower 广播COMMIT 消息，批准各个Server 执行该写操作事务。当各个Server 在接收到Leader 的COMMIT 消息后就会在本地执行该写操作，然后会向客户端响应写操作成功。
但是如果在非全部 Follower 收到 COMMIT 消息之前 Leader 就挂了，这将导致一种后果：部分 Server 已经执行了该事务，而部分 Server 尚未收到 COMMIT 消息，所以其并没有执行该事务。当新的 Leader 被选举出，集群经过恢复模式后需要保证所有 Server 上都执行了那些已经被部分 Server 执行过的事务。

当在 Leader 新事务已经通过，其已经将该事务更新到了本地，但所有 Follower 还都没有收到 COMMIT 之前，Leader 宕机了，此时，所有 Follower 根本就不知道该 Proposal 的存在。当新的 Leader 选举出来，整个集群进入正常服务状态后，之前挂了的 Leader 主机重新启动并注册成为了 Follower。若那个别人根本不知道的 Proposal 还保留在那个主机，那么其数据就会比其它主机多出了内容，导致整个系统状态的不一致。所以，该 Proposa 应该被丢弃。类似这样应该被丢弃的事务，是不能再次出现在集群中的，应该被清除。

前面我们说过，无论是写操作投票，还是 Leader 选举投票，都必须过半才能通过，也就是说若出现超过半数的主机宕机，则投票永远无法通过。基于该理论，由 5 台主机构成的集群，最多只允许 2 台宕机。而由 6 台构成的集群，其最多也只允许 2 台宕机。即，6 台与5 台的容灾能力是相同的。基于此容灾能力的原因，建议使用奇数台主机构成集群，以避免资源浪费。
但从系统吞吐量上说，6 台主机的性能一定是高于 5 台的。所以使用 6 台主机并不是资源浪费。

对于一个高可用的系统，除了要设置多台主机部署为一个集群避免单点问题外，还需要考虑将集群部署在多个机房、多个楼宇。对于多个机房、楼宇中集群也是不能随意部署的， 下面就多个机房的部署进行分析。
在多机房部署设计中，要充分考虑“过半原则”，也就是说，尽量要确保 zk 集群中有过半的机器能够正常运行。

在生产环境下，三机房部署是最常见的、容灾性最好的部署方案。三机房部署中要求每个机房中的主机数量必须少于集群总数的一半。

zk 官方没有给出较好的双机房部署的容灾方案。只能是让其中一个机房占有超过半数的主机，使其做为主机房，而另一机房少于半数。当然，若主机房出现问题，则整个集群会瘫痪。

CAP 定理又称 CAP 原则，指的是在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。

对于分布式系统，网络环境相对是不可控的，出现网络分区是不可避免的，因此系统必须具备分区容错性。但其并不能同时保证一致性与可用性。CAP 原则对于一个分布式系统来说，只可能满足两项，即要么 CP，要么 AP。

BASE 是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的简写。

BASE 理论的核心思想是：即使无法做到实时一致性，但每个系统都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。
损失响应时间：
损失功能：

软状态，是指允许系统数据存在的中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统主机间进行数据同步的过程存在一定延时。软状态，其实就是一种灰度状态，过渡状态。

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的一致性。

从达到一致性的时间角度来划分，可以分为：

单从客户端访问到的内容角度来划分，可以分为：

zk 遵循的是 CP 原则，即保证了一致性，但牺牲了可用性。体现在哪里呢？

当 Leader 宕机后，zk 集群会马上进行新的 Leader 的选举。但选举时长一般在 200 毫秒内，最长不超过 60 秒，整个选举期间 zk 集群是不接受客户端的读写操作的，即 zk 集群是处于瘫痪状态的。所以，其不满足可用性。

这里说的zk可能会引发脑裂，是指的在多机房部署中，若出现了网络连接问题，形成多个分区，则可能会出现脑裂问题，可能会导致数据不一致。
（1）情况一

（2）情况二

（5）情况五

kafkak配置仅允许受信任的JNDI连接如何配置

kafka的配置分为 broker、producter、consumer三个不同的配置

一 BROKER 的全局配置

最为核心的三个配置 broker.id、log.dir、zookeeper.connect 。
------------------------------------------- 系统 相关 -------------------------------------------

##每一个broker在集群中的唯一标示，要求是正数。在改变IP地址，不改变broker.id的话不会影响consumers

broker.id =1
##kafka数据的存放地址，多个地址的话用逗号分割 /tmp/kafka-logs-1，/tmp/kafka-logs-2

log.dirs = /tmp/kafka-logs
##提供给客户端响应的端口

port =6667
##消息体的最大大小，单位是字节

message.max.bytes =
## broker 处理消息的最大线程数，一般情况下不需要去修改

num.network.threads =3
## broker处理磁盘IO 的线程数 ，数值应该大于你的硬盘数

num.io.threads =8
## 一些后台任务处理的线程数，例如过期消息文件的删除等，一般情况下不需要去做修改

background.threads =4
## 等待IO线程处理的请求队列最大数，若是等待IO的请求超过这个数值，那么会停止接受外部消息，算是一种自我保护机制

queued.max.requests =500
##broker的主机地址，若是设置了，那么会绑定到这个地址上，若是没有，会绑定到所有的接口上，并将其中之一发送到ZK，一般不设置

host.name
## 打广告的地址，若是设置的话，会提供给producers, consumers,其他broker连接，具体如何使用还未深究

advertised.host.name
## 广告地址端口，必须不同于port中的设置

advertised.port
## socket的发送缓冲区，socket的调优参数SO_SNDBUFF

socket.send.buffer.bytes =100*1024
## socket的接受缓冲区，socket的调优参数SO_RCVBUFF

socket.receive.buffer.bytes =100*1024
## socket请求的最大数值，防止serverOOM，message.max.bytes必然要小于socket.request.max.bytes，会被topic创建时的指定参数覆盖

socket.request.max.bytes =100*1024*1024
------------------------------------------- LOG 相关 -------------------------------------------

## topic的分区是以一堆segment文件存储的，这个控制每个segment的大小，会被topic创建时的指定参数覆盖

log.segment.bytes =1024*1024*1024
## 这个参数会在日志segment没有达到log.segment.bytes设置的大小，也会强制新建一个segment 会被 topic创建时的指定参数覆盖

log.roll.hours =24*7
## 日志清理策略 选择有：delete和compact 主要针对过期数据的处理，或是日志文件达到限制的额度，会被 topic创建时的指定参数覆盖

log.cleanup.policy = delete
## 数据存储的最大时间 超过这个时间 会根据log.cleanup.policy设置的策略处理数据，也就是消费端能够多久去消费数据

## log.retention.bytes和log.retention.minutes任意一个达到要求，都会执行删除，会被topic创建时的指定参数覆盖

log.retention.minutes=7days

指定日志每隔多久检查看是否可以被删除，默认1分钟

log.cleanup.interval.mins=1
## topic每个分区的最大文件大小，一个topic的大小限制 = 分区数*log.retention.bytes 。-1没有大小限制

## log.retention.bytes和log.retention.minutes任意一个达到要求，都会执行删除，会被topic创建时的指定参数覆盖

log.retention.bytes=-1
## 文件大小检查的周期时间，是否处罚 log.cleanup.policy中设置的策略

log.retention.check.interval.ms=5minutes
## 是否开启日志压缩

log.cleaner.enable=false
## 日志压缩运行的线程数

log.cleaner.threads =1
## 日志压缩时候处理的最大大小

log.cleaner.io.max.bytes.per.second=None
## 日志压缩去重时候的缓存空间 ，在空间允许的情况下，越大越好

log.cleaner.dedupe.buffer.size=500*1024*1024
## 日志清理时候用到的IO块大小 一般不需要修改

log.cleaner.io.buffer.size=512*1024
## 日志清理中hash表的扩大因子 一般不需要修改

log.cleaner.io.buffer.load.factor =0.9
## 检查是否处罚日志清理的间隔

log.cleaner.backoff.ms =15000
## 日志清理的频率控制，越大意味着更高效的清理，同时会存在一些空间上的浪费，会被topic创建时的指定参数覆盖

log.cleaner.min.cleanable.ratio=0.5
## 对于压缩的日志保留的最长时间，也是客户端消费消息的最长时间，同log.retention.minutes的区别在于一个控制未压缩数据，一个控制压缩后的数据。会被topic创建时的指定参数覆盖

log.cleaner.delete.retention.ms =1day
## 对于segment日志的索引文件大小限制，会被topic创建时的指定参数覆盖

log.index.size.max.bytes =10*1024*1024
## 当执行一个fetch操作后，需要一定的空间来扫描最近的offset大小，设置越大，代表扫描速度越快，但是也更好内存，一般情况下不需要搭理这个参数

log.index.interval.bytes =4096
## log文件"sync"到磁盘之前累积的消息条数

## 因为磁盘IO操作是一个慢操作,但又是一个"数据可靠性"的必要手段

## 所以此参数的设置,需要在"数据可靠性"与"性能"之间做必要的权衡.

## 如果此值过大,将会导致每次"fsync"的时间较长(IO阻塞)

## 如果此值过小,将会导致"fsync"的次数较多,这也意味着整体的client请求有一定的延迟.

## 物理server故障,将会导致没有fsync的消息丢失.

log.flush.interval.messages=None
## 检查是否需要固化到硬盘的时间间隔

log.flush.scheduler.interval.ms =3000
## 仅仅通过interval来控制消息的磁盘写入时机,是不足的.

## 此参数用于控制"fsync"的时间间隔,如果消息量始终没有达到阀值,但是离上一次磁盘同步的时间间隔

## 达到阀值,也将触发.

log.flush.interval.ms = None
## 文件在索引中清除后保留的时间 一般不需要去修改

log.delete.delay.ms =60000
## 控制上次固化硬盘的时间点，以便于数据恢复 一般不需要去修改

log.flush.offset.checkpoint.interval.ms =60000
------------------------------------------- TOPIC 相关 -------------------------------------------

## 是否允许自动创建topic ，若是false，就需要通过命令创建topic

auto.create.topics.enable =true
## 一个topic ，默认分区的replication个数 ，不得大于集群中broker的个数

default.replication.factor =1
## 每个topic的分区个数，若是在topic创建时候没有指定的话 会被topic创建时的指定参数覆盖

num.partitions =1
实例 --replication-factor3--partitions1--topic replicated-topic ：名称replicated-topic有一个分区，分区被复制到三个broker上。
----------------------------------复制(Leader、replicas) 相关 ----------------------------------

## partition leader与replicas之间通讯时,socket的超时时间

controller.socket.timeout.ms =30000
## partition leader与replicas数据同步时,消息的队列尺寸

controller.message.queue.size=10
## replicas响应partition leader的最长等待时间，若是超过这个时间，就将replicas列入ISR(in-sync replicas)，并认为它是死的，不会再加入管理中

replica.lag.time.max.ms =10000
## 如果follower落后与leader太多,将会认为此follower已经失效

## 通常,在follower与leader通讯时,因为网络延迟或者链接断开,总会导致replicas中消息同步滞后

## 如果消息之后太多,leader将认为此follower网络延迟较大或者消息吞吐能力有限,将会把此replicas迁移

## 到其他follower中.

## 在broker数量较少,或者网络不足的环境中,建议提高此值.

replica.lag.max.messages =4000
##follower与leader之间的socket超时时间

replica.socket.timeout.ms=30*1000
## leader复制时候的socket缓存大小

replica.socket.receive.buffer.bytes=64*1024
## replicas每次获取数据的最大大小

replica.fetch.max.bytes =1024*1024
## replicas同leader之间通信的最大等待时间，失败了会重试

replica.fetch.wait.max.ms =500
## fetch的最小数据尺寸,如果leader中尚未同步的数据不足此值,将会阻塞,直到满足条件

replica.fetch.min.bytes =1
## leader 进行复制的线程数，增大这个数值会增加follower的IO

num.replica.fetchers=1
## 每个replica检查是否将最高水位进行固化的频率

replica.high.watermark.checkpoint.interval.ms =5000
## 是否允许控制器关闭broker ,若是设置为true,会关闭所有在这个broker上的leader，并转移到其他broker

controlled.shutdown.enable =false
## 控制器关闭的尝试次数

controlled.shutdown.max.retries =3
## 每次关闭尝试的时间间隔

controlled.shutdown.retry.backoff.ms =5000
## 是否自动平衡broker之间的分配策略

auto.leader.rebalance.enable =false
## leader的不平衡比例，若是超过这个数值，会对分区进行重新的平衡

leader.imbalance.per.broker.percentage =10
## 检查leader是否不平衡的时间间隔

leader.imbalance.check.interval.seconds =300
## 客户端保留offset信息的最大空间大小

offset.metadata.max.bytes
----------------------------------ZooKeeper 相关----------------------------------

##zookeeper集群的地址，可以是多个，多个之间用逗号分割 hostname1:port1,hostname2:port2,hostname3:port3

zookeeper.connect = localhost:2181
## ZooKeeper的最大超时时间，就是心跳的间隔，若是没有反映，那么认为已经死了，不易过大

zookeeper.session.timeout.ms=6000
## ZooKeeper的连接超时时间

zookeeper.connection.timeout.ms =6000
## ZooKeeper集群中leader和follower之间的同步实际那

zookeeper.sync.time.ms =2000

配置的修改

其中一部分配置是可以被每个topic自身的配置所代替，例如

新增配置

bin/kafka-topics.sh --zookeeper localhost:2181--create --topic my-topic --partitions1--replication-factor1--config max.message.bytes=64000--config flush.messages=1
修改配置

bin/kafka-topics.sh --zookeeper localhost:2181--alter --topic my-topic --config max.message.bytes=128000
删除配置 ：

bin/kafka-topics.sh --zookeeper localhost:2181--alter --topic my-topic --deleteConfig max.message.bytes

二 CONSUMER 配置

最为核心的配置是group.id、zookeeper.connect

## Consumer归属的组ID，broker是根据group.id来判断是队列模式还是发布订阅模式，非常重要

 group.id
## 消费者的ID，若是没有设置的话，会自增

 consumer.id
## 一个用于跟踪调查的ID ，最好同group.id相同

 client.id = group id value
## 对于zookeeper集群的指定，可以是多个 hostname1:port1,hostname2:port2,hostname3:port3 必须和broker使用同样的zk配置

 zookeeper.connect=localhost:2182
## zookeeper的心跳超时时间，查过这个时间就认为是dead消费者

 zookeeper.session.timeout.ms =6000
## zookeeper的等待连接时间

 zookeeper.connection.timeout.ms =6000
## zookeeper的follower同leader的同步时间

 zookeeper.sync.time.ms =2000
## 当zookeeper中没有初始的offset时候的处理方式 。smallest ：重置为最小值 largest:重置为最大值 anythingelse：抛出异常

 auto.offset.reset = largest
## socket的超时时间，实际的超时时间是：max.fetch.wait + socket.timeout.ms.

 socket.timeout.ms=30*1000
## socket的接受缓存空间大小

 socket.receive.buffer.bytes=64*1024
##从每个分区获取的消息大小限制

 fetch.message.max.bytes =1024*1024
## 是否在消费消息后将offset同步到zookeeper，当Consumer失败后就能从zookeeper获取最新的offset

 auto.commit.enable =true
## 自动提交的时间间隔

 auto.commit.interval.ms =60*1000
## 用来处理消费消息的块，每个块可以等同于fetch.message.max.bytes中数值

 queued.max.message.chunks =10
## 当有新的consumer加入到group时,将会reblance,此后将会有partitions的消费端迁移到新

## 的consumer上,如果一个consumer获得了某个partition的消费权限,那么它将会向zk注册

##"Partition Owner registry"节点信息,但是有可能此时旧的consumer尚没有释放此节点,

## 此值用于控制,注册节点的重试次数.

 rebalance.max.retries =4
## 每次再平衡的时间间隔

 rebalance.backoff.ms =2000
## 每次重新选举leader的时间

 refresh.leader.backoff.ms
## server发送到消费端的最小数据，若是不满足这个数值则会等待，知道满足数值要求

 fetch.min.bytes =1
## 若是不满足最小大小(fetch.min.bytes)的话，等待消费端请求的最长等待时间

 fetch.wait.max.ms =100
## 指定时间内没有消息到达就抛出异常，一般不需要改

 consumer.timeout.ms = -1
三 PRODUCER 的配置

比较核心的配置：metadata.broker.list、request.required.acks、producer.type、serializer.class

## 消费者获取消息元信息(topics, partitions and replicas)的地址,配置格式是：host1:port1,host2:port2，也可以在外面设置一个vip

 metadata.broker.list
##消息的确认模式

 ##0：不保证消息的到达确认，只管发送，低延迟但是会出现消息的丢失，在某个server失败的情况下，有点像TCP

 ##1：发送消息，并会等待leader 收到确认后，一定的可靠性

 ## -1：发送消息，等待leader收到确认，并进行复制操作后，才返回，最高的可靠性

 request.required.acks =0
## 消息发送的最长等待时间

 request.timeout.ms =10000
## socket的缓存大小

 send.buffer.bytes=100*1024
## key的序列化方式，若是没有设置，同serializer.class

 key.serializer.class
## 分区的策略，默认是取模

 partitioner.class=kafka.producer.DefaultPartitioner
## 消息的压缩模式，默认是none，可以有gzip和snappy

 compression.codec = none
## 可以针对默写特定的topic进行压缩

 compressed.topics=null
## 消息发送失败后的重试次数

 message.send.max.retries =3
## 每次失败后的间隔时间

 retry.backoff.ms =100
## 生产者定时更新topic元信息的时间间隔 ，若是设置为0，那么会在每个消息发送后都去更新数据

 topic.metadata.refresh.interval.ms =600*1000
## 用户随意指定，但是不能重复，主要用于跟踪记录消息

 client.id=""
------------------------------------------- 消息模式 相关 -------------------------------------------

 ## 生产者的类型 async:异步执行消息的发送 sync：同步执行消息的发送

 producer.type=sync
## 异步模式下，那么就会在设置的时间缓存消息，并一次性发送

 queue.buffering.max.ms =5000
## 异步的模式下 最长等待的消息数

 queue.buffering.max.messages =10000
## 异步模式下，进入队列的等待时间 若是设置为0，那么要么进入队列，要么直接抛弃

 queue.enqueue.timeout.ms = -1
## 异步模式下，每次发送的最大消息数，前提是触发了queue.buffering.max.messages或是queue.buffering.max.ms的限制

 batch.num.messages=200
## 消息体的系列化处理类 ，转化为字节流进行传输

 serializer.class= kafka.serializer.DefaultEncoder