• 2020-04-09

    C++ const& 的坑

    Views: 4415 | 1 Comment

    我们一般很喜欢把函数的参数定义为 const&, 这样即能传引用减少内存拷贝, 也能限定参数为 const 类型不可修改, 似乎很美好. 但是, 如果把对象的属性传给函数, 而对象又被删除时, 就会出错.

    struct C
    {
        std::string id;
    };
    
    class S
    {
        C *c = NULL;
    
        void f1(){
            c = new C();
            c->id = "a";
            f2(c->id);
        }
    
        void f2(const std::string &id){
            delete c;
            c = new C();
            c->id = "b";
            printf("deleted %s\n", id.c_str()); // core
        }
    };
    

    当然, 理论上是写代码的人的错误. 但是, 这确实是一个大坑. 我相信, 这种 case 在实际中还是有不少的. 函数的编写者可能仅仅把参数当作一个无害的对象, 完全没有意识到, 参数变量是和某个要销毁的对象是绑定的. 但是, 又不能强制规定 string 类型只能传值, 然后期待编译器能优化 string 类.

    真是坑.

    Posted by ideawu at 2020-04-09 16:21:10
  • 2020-04-05

    接口与实现分离

    Views: 2594 | No Comments

    我在遇到"接口与实现分离"这个编程领域的概念时, 感到非常模糊. 随着编程经验的积累, 才明白了"接口与实现分离". 用 Java 的程序员应该天天用到 interfalce 和 class, 不过, 即使是 Java 程序员, 可能偶尔也会违反广义的分离原则.

    我最近接触到的一个违反"接口与实现分离"原则的例子, 可以分享一下.

    RTT(round trip time)是一个非常重要的时间概念, 这会让程序变得很"慢". 例如:

    func(1);
    func(2);
    func(3);
    

    如果每一次函数调用要花 100ms 的话, 那么做完 3 件事要花 300ms. 有经验的程序员立即就做了代码"优化":

    func([1,2,3]);
    

    把函数参数改成数组, 一次传入 3 个任务, 利用了 batch 机制, 做完 3 件事也仅需要 100 ms. 看起来完美解决问题. 但是, 工程上这样做带来了缺点, 那就是改变了接口(interface). 这是一个经典的违反"接口与实现分离"原则的例子, 接口因实现而被迫改变.

    如果函数执行是放在网络服务器上面, 而调用者是所谓的客户端, 一般的网络编程都是可以并发处理的, 例如在 3 个线程中调用函数. 这时, 接口改变之后, 反而没有用. 因为任务是不同的客户端发起的, 除非你增加一层抽象来积累请求. 这个优化看起来美好, 但是却增加了使用者的成本.

    所以, 工程上应该由 func() 函数的实现者来做请求积累, 在函数内部把并发的请求合并成一个 batch, 减少 RTT.

    Posted by ideawu at 2020-04-05 12:15:41
  • 2020-03-09

    “一致性”是镜花水月

    Views: 3970 | No Comments

    Paxos 实现一致性的基础是每一次 touch 集群时, 都要走所谓的 2 phases. 这个 2 phases 是一个实实在在的写操作, 并没有所谓的只读. 对于 Paxos, 它并不关心是读操作还是写操作, 它要做的, 就是将数据复制到多个节点上. 有一种特殊情况下的优化, 那就是 Paxos proposer 获得了集群的全部副本, 并且知道全部副本都是完全相同的, 就不需要执行 phase 2.

    在某些情况下, 并不能这样优化, 因为等待全部节点返回结果, 可能消耗很长的时间. 而且, 某个节点故障时, 显然不应该等也等不到全部结果. 所以, 简单的做法是无论怎样, 都从多数派里获取最新的值, 然后要求所有节点都接受这个值(phase 2).

    所以, 对于 Paxos 来说, 要么全部节点都查询一遍(并且期望全部节点是完全相同的), 要么产生一个新的共识, 否则不能返回结果给客户端.

    这增加了系统的故障机率. 工程实践上极度厌恶"不可用", 追求的是"高可用", 所以, 很少人这样做, 也就是人们选择了 CAP 中的 AP.

    例如, 系统可以只读取唯一个节点, 返回该节点的数据即可. 这样做有工程上的价值. 如果某个节点故障, 换另一个节点继续尝试(例如一致性 hash).

    更进一步(更接近强一致性, 但仍然不是)的做法, 可以读取多数节点, 但不要求多数节点达成共识, 只返回多数节点之中最新版本的数据.

    这些对于读操作的优化, 都只能达到数据本身的"最终一致性", 从用户的观察角度看, 系统的状态在某个时间段是飘忽不定的(不一致). 无论你是否愿意承认, 只要你违反了 3 项原则中的任何一项, 你的系统就不是强一致性的. 不管你借鉴了 Paxos 还是 Raft. Raft 比较特殊一点, 把 Leader 当作存储共识的单点, 只需要查询 Leader 就能知道是否达成共识, 写或者读.

    强一致性既然那么难, 所以工程不太可能会去实现强一致性的系统. 正如前面所说, 大部分都对读操作进行了简化(优化). 那么, 写操作还是强一致的吗? 答案是否定的. 一旦读不是强一致性的, 写便不再是强一致性的. 一致性是对整个系统而言.

    那么, 很多借鉴了 Paxos 或者 Raft 的写流程的系统, 它们在做什么? 其实, 大部分只是利用了多数派顺序写特性. 多数派(多副本)是为了达到高可靠性, 顺序写是为了最终一致. 例如 Paxos 的 prepare 阶段就像是在申请全局递增的序号同时拷贝多副本, 而 accept 阶段是拷贝多副本.

    是的, 大部分系统最终实现的是高可靠, 高可用, 和最终一致性.

    Posted by ideawu at 2020-03-09 18:10:23 Tags: ,
  • 2020-03-07

    关于分布式存储的上帝视角和观察者视角

    Views: 3477 | No Comments

    我认为, 讨论分布式存储时, 一定要区分上帝视角和观察者视角, 否则经常会导致混乱. 上帝视角是指对多个副本进行同一时刻完整性的观察, 而观察者就是通常说的用户角度. 上帝的观察是非常绝对而准确的, 而且不会对系统产生任何作用. 而观察者则不是, 观察者的每一次观察可能会导致系统的状态发生改变. 例如, 对于 Paxos 来说, 读操作可能导致数据的写和删除.

    对于一个3个节点的集群, 我们说某一份数据存在两个副本, 这是上帝视角的观察. 从用户的角度来观察, 可能观察到0到2个副本. 一致性协议要解决的一般是观察者的线性一致性, 同时要隐藏副本数量, 只让观察者看到数据的存在或者不存在, 而不是副本的数量.

    一个很经典的一致性问题, 在3个节点的集群中, 如果上帝视角看到是两个副本, 那么观察者第一次看到是存在(按多数派来决定是否存在), 那么第二次观察就不能说不存在.

    之前讨论过, 即使上帝看到2/3多数派副本存在, 观察者的观察结果未必就是存在. 如果观察者观察时只看到两个节点其中一个节点无数据, 这种情况就是所谓的 unknown(未决, uncommitted). 因为观察者讨厌 unknown, 所以, Paxos 会更新集群的状态(同步数据), 让集群的状态变成 committed.

    回到线性一致性的问题来, 如果第二次观察时, 虽然不能说不存在, 但可以说 unknown, 这并不违反系统的一致性原则. 不过, 违反了高可用原则.

    分布式系统, unknown 状态是一个非常重要的概念. 上帝视角没有 unknown, 但观察者视角有. 我们有上帝视角, 但集群的用户只有观察视角, 一定要注意.

    Posted by ideawu at 2020-03-07 19:10:12 Tags:
  • 2020-03-07

    为什么 Leader Based 的分布式协议 Raft 是更好的

    Views: 4460 | 1 Comment

    为什么 Leader Based 的分布式协议 Raft 是更好的? 这个问题隐式地表达了 Paxos 多主特性是不好的. 之前谈过, Paxos 不区分读写, 读和写都要进行完整的 Paxos prepare-accept 两阶段流程, 否则, 就无法保证一致性. 事实上, 我看过一些 Paxos 实现, 它们基于优化的考虑, 简化了 prepare-accept 两阶段流程, 最终失去了一致性保证而不自知. 可见, 优化是万恶之源.

    一个常见的错误是把多数派读当做一致性读, 之前已经谈过, 这是错误的.

    但是, 为什么大家一而再, 再而三地一定要优化 Paxos 呢? 很显然, 大家已经发现 Paxos 的理论模型在很多场景并不实用(请原谅我这么直白, 你可以自己想象成非常委婉的语言). 于是, 每个人都按自己的理解去简化 Paxos 实现, 然后错误地拿"Paxos"来当挡箭牌证明自己拥有 Paxos 的所有优点, 而不知道自己犯了逻辑上不严谨的错误, 只是因为计算机和网络环境出错的概率比较小, 而自己的代码其它部分又有 bug, 所以不愿意把 bug 算到自己错误地简化了 Paxos 这个做法头上.

    我发现, 错误的 Paxos 实现各有各的不同, 而正确的 Paxos 实现最终都实现成了 Raft 的样子.

    首先, 日志复制状态机的理论更有普适的实际意义. Multi-Paxos 错误地暗示要实现成以 key 为维度, 但现实世界的数据是结构化的, KV 是特例. 结构化要求不能以离散的 key 为维度来同步数据, 而是应该同步数据的操作序列, 也就是日志复制. 所以, 除非全量同步数据, 否则把 Paxos 应用到结构化数据上面一定会带来严格意义上的错误的.

    其次, Leader Based 是更有普适意义的一种理论上已经证明具有严谨性和正确性的优化手段. 我所见过的任何不基于选主的对 Paxos 进行优化的方案, 几乎全是错误的, 都没有理论上的严谨证明, 实际上的错误也显而易见. 如果你的 Paxos 实现不是基于选主的, 同时你又意图做优化, 那么, 我几乎非常确定, 你已经犯错了.

    为什么优化必须先选主? 之前的文章已经谈过, 多个副本数据的不一致性是一定的, 没有任何协议和手段能避免, 所有的一致性协议都是让数据看起来一致来让自己具有一致性功能. 当多个副本不一致时, Paxos 要求在读和写的时候同步数据, 来修复这种不一致, 修复完后才能返回给客户端. 但是, 所有的优化都破坏了这个原则, 然后声称自己对 Paxos 做了优化. 哪有这样的好事? 你破坏了 Paxos 基石, 却没有提供对等的理论证明.

    再回到选主这个话题. 选主的一个重要作用, 就是对多副本的不一致性进行统计和确认. 一个简单的例子, 当某个 key 只存储于一个节点或者两个节点, 无论是多数节点还是少数节点没关系, 那么这个 key 到底是不是有效的? Paxos 的做法是读的时候做同步. 有一个非常违反直觉的的地方, 那就是, 如果数据存在于多数节点, 那么这个数据是否是有效的呢? 答案仍然是未知的

    很违反常理, 是不是? 设想这样一场景, 当你去读这份数据时, 你会遇到两个情况: 一是多数节点有共识, 二是没有多数节点共识. 对于有共识, 很简单, 那就是有共识. 但是, 对于无共识, 除非你读到了所有节点的明确的答复, 否则你不能确定是否有共识, 因为还有节点未答复.

    但是, 如果有 Leader, 那么 Leader 自己就能确定, 不需要读"全部"节点. 这就是做了优化. 现在, 问题就剩下怎么避免出现两个"自认"的 Leader. 这也是 Raft 要解决的问题.

    Posted by ideawu at 18:47:08 Tags: ,
  • 2020-03-07

    Raft 选主优化之 PreVote

    Views: 3755 | No Comments

    Raft 的论文介绍了一种普适性的分布式一致性协议, 但在工程实际上, 不太可能完全照搬论文实现, 因为工程上应对很非理想状况下的场景. 工程上实现 Raft 时, 单单是集群选主这个环节, 就会引入一些 Raft 协议本来没有的概念, 比如 PreVote.

    在实际使用时, 当网络分区出现时, 被隔离的节点会不断增加 currentTerm 并发起选主流程. 当网络恢复时, 它的 currentTerm 比其它所有的节点都要大, 所以, 它将导致原来的 Leader 变成 Follower 然后重新选主. 这种情况其实是非常不好的, 原来的 Leader 工作得好好的, 突然就被一个不稳定的节点给破坏了.

    所以, 要引入 PreVote, 在发起选主前, 一是判断是否和其它节点能网络连通, 二是询问其它节点是否要选主. 如果 Follower 最新刚刚收到了 Leader 的心跳包, 它就不同意选主.

    Leader 也要对 PreVote 请求进行响应, 而不能忽略. 因为在双节点集群时, 如果 Leader 不响应 PreVote, 那么两个节点永远都选不出新 Leader. Leader 通过心跳包和 Followers 保持联系, 如果失去联系, 它不会发起选主流程, 而是继续认为自己仍然是 Leader. 当收到 PreVote 时, 它要同意新的选主流程.

    Posted by ideawu at 16:14:26 Tags:
|<<<123456789>>>| 3/129 Pages, 773 Results.