BPM优化
本文借15445的爬Rank的契机,来进行对于BPM设计上的优化,进而来分析如何优化并发的设计。这是一次相当有趣的设计体验。其中所需要的经历相当的多,同时也收获很多。
本文进行对于Scaling Memcache at Facebook一文的部分内容摘取
本专栏用于部分书中优质内容的摘抄,请注意,只是那部分相对来说对于我个人感触较大的,不是对于全部内容,叠个盾()
从事服务端开发,领域知识是最基础却又最重要的能力。但是,只有当领域知识形成体系的时候,才可能成为真正的核心竞争力。当遇到问题时,如果连相关的知识储备都没有,那么往往很难解决问题;而如果你有相应的知识储备,则可以将知识迁移到问题场景中,辅以推理寻找解决问题的方法。为了能够让领域知识和逻辑推理能够更好的结合,我们需要系统地学习知识,专注于某些技术方向的同时,有意识的向周边进行扩展。就比如,对于后端开发工程师,除了掌握服务端开发技术栈和相关业务知识,也应该了解一些客户端的知识,了解客户端与服务端之间如何进行交互。
很多时候,领域知识点本身是可以相互联系起来的,但是前提是你对于这些知识点的理解足够透彻。在工作中学习,最常陷入的困境是时间过于碎片化,学了后面的,就网络前面的,不得要领。这个现象其实在一般的学习中也会广泛的存在,就比如在对于一些网课的学习中,如果是粗浅的过,那么最后只会是一种模糊的印象,甚至于刚看完的课程不一会就忘记了。出现这种情况的一个很重要原因在于:领域宏观层面的整体视图没有形成,关键知识点理解深度不够、不透彻。这些关键知识点就是这个领域的骨架、支点。缺了骨架,自然难以体系化,缺了支点,则容易误入歧途。
上面这段理论其实与OSTEP中的一个论点很接近,就是关于一个章节或者说一个书本内容的学习,其中最重要的是形成一个自己的心智模型。什么是心智模型,在目前的我看来,一个心智模型是在你看到一个物品时,你能够联想到的关于这个物品背后所涉及到的一系列你领域知识内的东西。
举个例子,当你看到一个服务器集群在运行时,你不免会去猜想其中所用的共识算法到底是什么,是Paxos还是Raft。再进一步,当你想到一个共识算法时,你会去考虑对应的内部到底是怎么达成共识的,对应的在网络分区(P)未发生的情况下,其对应的一致性(C),可用性(A),都是怎么实现的。因此,你会很快的想到Raft中使用Leader Election机制和单主复制等来协调集群,进而来实现一种一致性。当发生P时,其通过心跳来检测活性并通过发起新一轮Leader Election等来实现在节点少部分故障时候的可用性。其会在节点落后进度落后时通过InstallSnapshot来追赶对应的进度,而且通过相互之间的信息量来约束对应的选举结果,但是最终是一种尽力而为的模型等等。
总总这些,是本人在学习分布式的共识算法后形成的一些简单的心智模型,或者说,是剩下的那些比较印象深刻的知识点,整体的Raft算法在学习时实际上是比上文描述的麻烦且复杂许多的,但是对于我来说我是无法全部记住的,只能根据实际的一些场景记录下一些重要的知识点,即所谓的支点。在经历过一段时间过后,剩余的知识点实际上构成了一个基本的蓝图。在初始时候不必追求完美企图全部记住,因为这个是不现实的,只有在实际的实践中,我们才能够不断的将这些个知识点内化,纳入为骨架中的一部分。进而形成自己的一个完整心智模型。