Blog

分布式机器间的心跳检测

Question #

机器间的心跳检测机制是指在分布式环境中,不同机器之间需要检测到彼此是否在正常运行,例如 A 机器需要知道 B 机器是否正常运行。如何使用ZooKeeper 来实现分布式机器间的心跳检测?

Answer #

在传统的开发中,我们通常是通过主机之间是否可以相互PING通来判断,更复杂一点的话,则会通过在机器之间建立长连接,通过 TCP 连接固有的心跳检测机制来实现上层机器的心跳检测,这些确实都是一些非常常见的心跳检测方法。

基于ZooKeeper的临时节点特性,可以让不同的机器都在ZooKeeper的一个指定节点下创建临时子节点,不同的机器之间可以根据这个临时节点来判断对应的客户端机器是否存活。通过这种方式,检测系统和被检测系统之间并不需要直接相关联,而是通过ZooKeeper上的某个节点进行关联,大大减少了系统耦合。

临时节点的生命周期和客户端会话绑定,一旦客户端会话失效,那么这个客户端创建的所有临时节点都会被移除。

Viewpoint #

From #

99%尾延迟

Question #

什么是99% 尾延迟?

Answer #

我们把所有请求的处理延迟从小到大排个序,99% 的请求延迟小于的值就是 99% 尾延迟。比如说,我们有 1000 个请求,假设按请求延迟从小到大排序后,第 991 个请求的延迟实测值是 1ms,而前 990 个请求的延迟都小于 1ms,所以,这里的 99% 尾延迟就是 1ms。

Viewpoint #

From #

toc:MachineLearning

Content #

批处理模式与随机梯度下降法 强可学习的(strongly learnable) 线性回归的正则化 效用函数(utility function)与成本函数(cost function) 经验风险(empirical risk) 单词文本矩阵(word-document matrix) ID3算法的缺陷 Softplus函数 F测度 用户画像的RFM值 Risk Ratio 因训练集样本的不充分导致分类错误 Kullback-Leibler距离 KL距离的不对称性 精确率与召回率

sklearn #

三种朴素贝叶斯算法各自适用的场景

From #

强可学习的(strongly learnable)

Question #

什么是强可学习的(strongly learnable)?

Answer #

在概率近似正确(probably approximately correct, PAC)学习的框架中,一个概念,如果存在一个多项式的学习算法能够学习它,并且正确率很高,那么这个概念是强可学习的。

Viewpoint #

From #

单例模式的缺陷

单例模式存在哪些问题? #

  1. 单例对 OOP 特性的支持不友好
  2. 单例会隐藏类之间的依赖关系
  3. 单例对代码的扩展性不友好
  4. 单例对代码的可测试性不友好
  5. 单例不支持有参数的构造函数

Viewpoint #

From #

席克定律

Question #

在信息理论中,尤其是在网页界面设计领域之中,有一个普遍的法则,被称之为“席克定律”。什么是“席克定律”?

Answer #

它指的是“用户作决定花费的时间长度,和他所面临的选项数量成正比”。简单来说就是,设计车辆驾驶席或家用电器的操作面板时,选项设计得越多,越容易令使用者陷入迷茫,从而花费更多的时间去做决定。

Viewpoint #

From #

权责发生制

什么是权责发生制? #

以权利或责任的发生来确定应收和应付,不考虑是否在本期收到或付出现金。

Viewpoint #

From #

假设历史是符合某种逻辑的

Content #

心理学家P·C·沃森(P.C.Wason)实施做了如下实验。他把2、4、6这个数字序列放在受试者面前,请他们猜出背后的规律。猜测的方法是受试者举出别的由三个数字组成的序列,受试者根据新序列是否符合同样的规律回答“是”或“否”。一旦从实验者的答案中获得确信,受试者就可以写出规律。正确的规律是“按升序排列的数字”,仅此而已。

很少受试者发现了这一规律,为什么?沃森从这个实验中得到了什么结论?这个实验与历史规律问题有何相似之处?

因为要想找到规律,他们必须举出降序的数字序列(好让实验者的回答为“否”)。沃森注意到,受试者头脑中有一个规律,他们举出旨在证明它的例子,而不会尝试举出与他们的假设不一致的例子。受试者顽固地试图证明他们编造的规律。

这一实验与历史规律问题的相似性:假设历史是符合某种逻辑的,我们只看到了事件,却从来看不到规律,但必须对它作出猜测。

Viewpoint #

From #

全局偏移表 (Global Offset Table, GOT)

地址无关代码的核心结构 #

在计算机科学领域,有一句名言:“计算机领域的所有问题都可以使用新加一层抽象来解决”。这句话的应用在计算机领域随处可见。同样地,要实现代码段的地址无关代码,思路也是通过添加一个中间层,使得对全局符号的访问由直接访问变成间接访问。

可以引入一个固定地址,让引用者与这个固定地址之间的相对偏移是固定的,然后这个地址处再填入 foo 函数真正的地址。当然,这个地方必然位于数据段中,是每个进程私有的,这样才能做到在不同的进程里,可以访问不同的虚拟地址。这个新引入的固定地址就是全局偏移表 (Global Offset Table, GOT)。GOT 的工作原理如下图所示:

在上图中,call 指令处被填入了 0x3000,这是因为进程 1 的 GOT 与 call 指令之间的偏移是 0x5000-0x2000=0x3000,同时进程 2 的 GOT 与 call 指令之间的偏移是 0x8000-0x5000=0x3000。所以对于这一段共享代码,不管是进程 1 执行还是进程 2 执行,它们都能跳到自己的 GOT 表里。

然后,进程 1 通过访问自己的 GOT 表,查到 foo 函数的地址是 0x1000,它就能真正地调用到 foo 函数了。进程 2 访问自己的 GOT 表,查到 foo 函数的地址是 0x2000,它也能顺利地调用 foo 函数。这样就通过引入了 GOT 这个间接层,解决了 call 指令和 foo 函数定义之间的偏移不固定的问题。

这种技术就是地址无关代码 (Position Independent Code, PIC)。

Viewpoint #

From #

07 | 动态链接(上):地址无关代码是如何生成的?

...