beanstalkd是一个使用还算广泛的开源消息队列，由c语言编写。因为本身功能简单，代码也不多，所以阅读可以帮助我快速复习一下网络编程，并且麻雀虽小，五脏俱全，一个c语言项目的方方面面它也都包含了。 ---入口 万事先从main函数开始： int main(int argc, char **argv) { //用来存储服务端生成的socket的fd int r; //job的链表 struct job list = {}; //程序名字 progname = argv[0]; //设置为行buffer模式，具体参见man手册，遇到换行即发送到目标 setlinebuf(stdout); //解析输入参数

前段时间前同事找我看了这么一段代码： (new Pipeline($this->container)) ->send($passable) ->through($middleware) ->then($destination); 是laravel框架里看起来很直观的一段调用逻辑，把container注入到Pipeline对象，然后将passable(其实一般是$request对象)发送通过一连串的中间件，最后到达目的地(最终的processHandler之类的函数)。 看起来很不错是不是，再看看laravel内部的实现，代码在Illuminate\Pipeline下： class Pipeline implements PipelineContract { protected $container; /** * The

其实有了那篇服务开发总结，这篇看起来没什么必要了，不过作为纯技术的总结还是发出来吧。 在前几篇中说到了es的jdbc工具，这个工具确实挺好，可以满足一些不想要开发量的小公司的要求。 但从我们使用的过程中也看出了这个工具的一些缺陷： 1.方案强依赖于数据库表的时间戳。 不靠谱，你不能要求你的业务RD或者老的遗留系统能够满足你的这些规范方面的要求(刚从dc出来的时候感觉很多规范方面的事情是应该做的，但根据工作经历来看，设计技术方案最好还是要考虑到最坏的情况)。 2.这个工具每一个脚本只能执行一条sql语句。 这是一个比较重大的缺陷，因为工具本身是java写的，这就意味着每个脚本都是在独立的jvm里跑。而jvm，你懂的。基本一台64GB的机器跑个七八个脚本，再加上es本身，内存就快要爆掉了。而实际上这件事情本身不应该需要这么大的硬件成本。 3.读写分离问题导致的数据延迟问题。 这条其实是1衍生出来的，同样考虑最坏的情况，主从延迟如果到了一定程度，那么在脚本运行期间内会导致时间戳前进之后，有旧数据入到从库。那么脚本的逻辑就会产生数据丢失。

前几天在公司做了一次分享，其实是类似于工作汇报的东西。。。顺便记了一些东西，整理一下吧： 这个服务完成了的事情 1).独立的es集群 目前线上正在运行的版本是1.7.3 三台机器，总数据量大概在100G左右(算上分片的冗余) 集群上安装有head、bigdesk、ik分词器等插件 存在的问题： es版本其实已经有点老了。。官方在2.1和2.2又加入了一些新特性，这些特性在老版本里我们享受不到，当然现在的接入功能也比较简单，也不一定用得到。但不升级自然就享受不到官方版本升级带来的红利：新功能，新bug 2).在es之前封装了一层web服务 用golang的web框架gin > https://github.com/

在上次的一致性哈希讲解中，提到了虚拟结点的生成算法。说得不怎么明白，本文将会对常用的两种虚拟结点生成算法进行一些简单的解析。 我们以Google的groupcache和经典应用memcached来做例子进行说明。 首先是groupcache，在groupcache中生成虚拟结点的算法代码如下： func (m *Map) Add(keys ...string) { for _, key := range keys { for i := 0; i < m.replicas; i++ { hash := int(m.hash([]byte(strconv.Itoa(i) + key)