ITPub博客

zookeeper是一个强一致【不严格】的分布式数据库，由多个节点共同组成一个分布式集群，挂掉任意一个节点，数据库仍然可以正常工作，客户端无感知故障切换。客户端向任意一个节点写入数据，其它节点可以立即看到最新的数据。

折腾了一周的 Java Quartz 集群任务调度，很遗憾没能搞定，网上的相关文章也少得可怜，在多节点（多进程）环境下 Quartz 似乎无法动态增减任务，恼火。无奈之下自己撸了一个简单的任务调度器，结果只花了不到 2天时间，而且感觉非常简单好用，代码量也不多，扩展性很好。

我们的业务中经常会遇到穿库的问题，通常可以通过缓存解决。 如果数据维度比较多，结果数据集合比较大时，缓存的效果就不明显了。 因此为了解决穿库的问题，我们引入Bloom Filter。

Go语言内置运行时（就是runtime），抛弃了传统的内存分配方式，改为自主管理。这样可以自主地实现更好的内存使用模式，比如内存池、预分配等等。这样，不会每次内存分配都需要进行系统调用。

Go 语言最流行了两个轻量级 Web 框架分别是 Gin 和 Echo，这两个框架大同小异，都是插件式轻量级框架，背后都有一个开源小生态来提供各式各样的小插件，这两个框架的性能也都非常好，裸测起来跑的飞快。本节我们只讲 Gin 的实现原理和使用方法，Gin 起步比 Echo 要早，市场占有率要高一些，生态也丰富一些。

为了保证系统能够对机房级别的故障进行容错,不会使系统不可用,这就需要在机房级别对系统进行冗余处理。而这就需要在架构上进行良好的设计。来面对多机房场景下的技术挑战。事实上，异地多活最大的挑战在于机房之间的物理距离更远,数据传输的延迟已经不能忽略。在网络普遍延迟的情况下,如何根据业务特性设计高可用的性能达标的分布式系统,将是最大的挑战。

LevelDB 的键值对内容都存储在扩展名为 sst 的 SSTable 文件中，SSTable 的磁盘文件结构比较复杂，读者在阅读本节之前要做好心理准备。如果有任何看得不明白的地方，一定要在下方的问答区及时提问。

defer是Go语言提供的一种用于注册延迟调用的机制：让函数或语句可以在当前函数执行完毕后（包括通过return正常结束或者panic导致的异常结束）执行。深受Go开发者的欢迎，但一不小心就会掉进它的温柔陷阱，只有深入理解它的原理，我们才能轻松避开，写出漂亮稳健的代码。

本来没想写这个题材的，为了某某童鞋能够更好的茁壮成长，临时写一篇负载均衡的。负载均衡，大家可能听过什么3层负载均衡、4层负载均衡、7层负载均衡什么的？那这是怎么分的呢，ok，是根据osi七层网络模型来分的，例如nginx是工作在应用层，应用层刚好是在第7层，因此nginx又可以称为7层负载均衡。 我本来想一层层慢慢讲，从最基础的网络协议开始讲起，想了想又觉得这种讲法不适合速成。因此我改变思路，直接讲负载均衡架构的演进，最后的成品就可以在面试中侃一侃，因为现在负载均衡基本都是这套架构！

上一篇文章中，我们学会了用wireshark和tcpdump来分析TCP的“三次握手，四次挥手”，非常好用。这哥俩就是传说中的 锤子，拿着 锤子，看什么都像 钉子！在这篇文章中，我对准了 HTTP这颗钉子砸下去，咳咳。

在 LevelDB 数据库中高层数据下沉到低层时需要经历一次 Major Compaction，将高层文件的有序键值对和低层文件的多个有序键值对进行归并排序。磁盘多路归并排序算法的输入是来自多个磁盘文件的有序键值对，在内存中将这些文件的键值对进行排序，然后输出到一到多个新的磁盘文件中。

假设我们希望给某个用户限制调用某个 API 的总 QPS 为 50，但机器数可能很多（比如有 100 台）。这时候我们很自然地就想到，找一个 server 专门用来统计总的调用量，其它的实例都与这台 server 通信以判断是否可以调用。这就是最基础的集群流控的方式。

阿里巴巴 “大中台、小前台”机制的提出，某种程度上是从传统的事业部制向准事业部制的转换。就阿里巴巴而言，“前台”就是贴近最终用户/商家的业务部门，包括零售电商、广告业务、云计算、物流以及其它创新业务等；而“中台”则是强调资源整合、能力沉淀的平台体系，为“前台”的业务开展提供底层的技术、数据等资源和能力的支持，中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。

不善言谈的优秀程序员在面试中往往是要吃巨亏的，你没有办法通过说话来轻易证明自己的实力。不论是大厂还是小厂，大部分面试官都不具备优秀的面试能力，它们也只能通过三言两语观察一下面试者的表面工夫。老钱就是这样吃了很多亏的程序员，不喜欢准备面试，不喜欢吹嘘虚假的不存在的经验和能力，甚至连网上的笔试题都懒得做，因为在实际工作中这些鸟题根本一点都用不上。

全局事务服务（Global Transaction Service，简称 GTS）是阿里新推出的分布式事务处理方案，对其深入分析的资料相对匮乏。本文的目标是剖析GTS的技术路线，厘清其优势与约束。文章参考了GTS公开的专利、产品文档、相关网页，文章中肯定有不准确的地方，欢迎各位同学拍砖与指正。

本节信息量很大，我们要从整体上把握 LevelDB 这座大厦的结构。当我们熟悉了整体的结构，接下来就可以各个击破来细致了解它的各种微妙的细节了。

文字是社会发展到一定阶段的产物。原始社会时期，人群、部落之间交流较少，有声语言已能满足需要。后来，随着社会生产的发展，人们的社会交际日趋频繁，而有声语言一发即逝，既不能传诸远方，亦不能留诸异日，用它作为传递思想信息的唯一手段，已越来越不能满足需要了。

LevelDB 的大致原理已经讲完了，本节我们要亲自使用 Java 语言第三方库 leveldbjni 来实践一下 LevelDB 的各种特性。这个库使用了 Java Native Interface 计数将 C++ 实现的 LevelDB 包装成了 Java 平台 的 API。其它语言同样也是采用了类似 JNI 的技术来包装的 LevelDB。

再过不到 2 个月，互联网行业就要再次迎来面试高峰了。为了让大家能顺利通过所有面试环节必经的笔试阶段，我提前给大伙准备了一套常见的算法笔试题。这套算法题来源于 LeetCode，题目都是 BAT、京东头条滴滴美团等大型互联网公司都喜欢考的题目。

不得不说 SpringBoot 太复杂了，我本来只想研究一下 SpringBoot 最简单的 HelloWorld 程序是如何从 main 方法一步一步跑起来的，但是这却是一个相当深的坑。你可以试着沿着调用栈代码一层一层的深入进去，如果你不打断点，你根本不知道接下来程序会往哪里流动。这个不同于我研究过去的 Go 语言、Python 语言框架，它们通常都非常直接了当，设计上清晰易懂，代码写起来简单，里面的实现同样也很简单。但是 SpringBoot 不是，它的外表轻巧简单，但是它的里面就像一只巨大的怪兽，这只怪兽有千百只脚把自己缠绕在一起，把爱研究源码的读者绕的晕头转向。但是这 Java 编程的世界 SpringBoot 就是老大哥，你却不得不服。即使你的心中有千万头草泥马在奔跑，但是它就是天下第一。如果你是一个学院派的程序员，看到这种现象你会怀疑人生，你不得不接受一个规则 —— 受市场最欢