趁着年轻

geth代码时， 到p2p/discover/udp.go readLoop()函数的处理的时候，直接一个死循环没有监听closing管道，所以基本上是不能优雅退出的。
可能是作者觉得这个不重要，所以没管它？

阅读全文...

上一篇geth以太坊源码学习-启动服务1写到geth（）入口函数，这里继续后面看看以太坊是怎么创建一个节点，并且启动服务的。
再看下geth函数，主要是节点创建函数makeFullNode 和启动函数 startNode ， 后者会创建协程启动节点，然后进入等待状态。

阅读全文...

最近区块链这么火，出于好奇想看看源码实现，比较著名的就是比特币和以太坊了，前者是始祖，后者因为有智能合约的存在，所以大量不会写区块链底层的人可以利用以太坊实现自己的链，实际上，就是ICO， token了。
找了两者的官方源码：比特币 和 以太坊， 由于之前对C，C++源码看的多一些，所以这回趁这机会再了解一下go怎么实现以太坊的。

阅读全文...

上篇文章介绍了一下nsqlookupd 启动服务的简单流程，限于篇幅到这里来写一下nsqlookupd主要的工作：通道注册登记，以及查询服务。
nsqlookupd 有两个主要的功能：

1. nsqd来注册所有topic、channel的分布信息，nsqlookupd记录哪些topic在哪些机器上；
2. 给消费端来查询对应的topic所在的机器列表，以供订阅消费；

阅读全文...

之前的文章写了nsqd的代码逻辑，这里简单介绍一下作为负载均衡或者消息topic/channel汇总的nsqlookupd 的实现原理。相对来说nsqlookupd 比nsqd简单很多，不需要持久化，不需要太多的携程，也没有那么多channel。因此这里简单介绍一下。

nsqlookupd作为其他nsqd的中心，主要负责topic的等级注册，以及channel的登记注册，topic位置查询等服务。生产者一般可以不用连接nsqlookupd，但是消费者在消费时，如果是分布式环境就得连接nsqlookupd，查询指定topic在哪些机器上，进而连接对应的机器，SUB上去消费内容。这里类似redis的集群方案，只是redis集群是纯分散的，而nsqd则是把这个任务交给了nsqlookupd, 这样有利有弊，设计结构复杂一些，但是nsqlookupd的存在让服务维护容易，并且模块清晰一些。

阅读全文...

这里记录一下消息的消费者订阅流程，配合上面文章写的消息发送流程。不过这里暂时没讲lookupd的过程，后面在详细介绍。

1. 消费者使用TCP协议，发送SUB topic channel 命令订阅到某个channel上，记录其client.Channel = channel，通知c.SubEventChan；
2. 消费者启动后台协程protocolV2.messagePump订阅c.SubEventChan 并得知channel有订阅消息；
3. 开始订阅管道subChannel.memoryMsgChan/backend， 每个客户端都可以订阅到channel的内存或者磁盘队列里面;
4. 待生产者调用第四步后，其中一个client会得到消息：msg := <-memoryMsgChan;
5. 客户端记录StartInFlightTimeout的发送中消息队列，进行超时处理；
6. SendMessage 将消息+msgid发送给消费者；
7. 消费者收到msgid后，发送FIN+msgid通知服务器成功投递消息，可以清空消息了；

阅读全文...

本文从消息发送者的PUB到最后消息被SUB接收，整个流程串起来讲一下nsqd是怎么接收消息的，这部分先写发送流程。

1. 生产者PUB topic消息；
2. topic.PutMessage 到 topic.memoryMsgChan；
3. 每topic消息有后台协程topic.messagePump进行Topic.memoryMsgChan监听；
4. topic.messagePump 遍历每个channel调用channel.PutMessage发送消息到channel.memoryMsgChan ;

阅读全文...

写一下Channel的实现，比topic相对简单一些，但channel是最接近消费者端的，有他特有的东西，包括投递，确认等；
nsqd的channel的作用在于能对指定的队列topic，进行多份投递，或者说消费，一份队列可以给多个消费者重复消费，有点类似于kafka的consumer_group，每个consumer_group拥有独立的position， 不同group之间可以消费同一份内容的多个副本。
这里稍微做个对比，kafka的已经消费国的消息是可以继续保留的，而nsq则如果消费完了，就会删除掉，也就是没有position可以供回溯，或者重复消费，只要客户端发发送FIN后，消息就会销毁，也不会保留在磁盘上面，这点比kafka简单多了，当然，轻量级消息队列也不太需要这么复杂的功能。

阅读全文...

这回记录一下nsqd的topic是怎么实现的。先以官网一张著名的动图开始， 下面这图介绍了发送一条消息到一个topic上的流程：

阅读全文...

前段时间了解Go语言，开始了解Go的优秀开源服务，所以找出NSQ学习一下，下载了一份nsq源码开始学习，顺便记录一下阅读的笔记。

对协程实现原理感兴趣的话推荐看一看libtask，几年前在看源码的时候写过2篇笔记，里面有代码和注释：libtask协程库实现源码学习

NSQ是一个实时分布式消息处理服务，支持分布式，其源码包括：
1. nsqd 作为一个主要的消息接受，发送， 跟客户端沟通的后台进程，负责监听客户端连接，处理客户端的发送接收请求；
2. nsqlookupd 是一个管理进程，其他所有nsqd启动会尝试不断连接他，上报topic信息等；
3. nsqadmin 管理进程；
4. 其他便利工具；

阅读全文...

还记得，深夜，你在Redis 命令行里敲入"keys *" 后，线上开始报警，然后只能举起双手焦急的等待几千万key被慢慢扫描几十分钟还没结果，束手无策的时候，你跟所有redis用户拥有同样的心声：“就不能温柔点让我遍历一遍所有的数据吗？”
要知道，遍历一下数据库里面的所有数据，是多么理所应当的要求，这在mysql等关系型数据库眼里是多么的不可理解的。

阅读全文...

今天中午订了份外卖，应该是超时了，后来外卖小哥给我打电话下楼取餐，因为正好忙着工作所以电话里跟他说“你试试能不能走货梯上来，如果上不来的话跟我电话说一声我下来”，然后我隔了一会后就去21层货梯门口等，没给我打电话应该是走货梯上来了，等了几分钟后一抬头，发现他突然出现在眼前，半跪着在地上上气不接下气的，跟我进行了下面的对话： 阅读全文...

正直，比什么都重要。

最容易出bug的，不是代码，而是人。人与人打交道，有利可图的各种灰色case。

正义，最终会战胜邪恶。

一个app做久了，自己人可能都习以为常了，认为xxx设计这样就是最好的了，当初讨论了很久云云，没有再优化的空间了。

比如社交，影响一个用户最主要的： 阅读全文...

一不小心16年了，26岁多了，很多事情都要来了。
希望新的一年自己能依旧保持这份不拘的性格，不过稳定的生活，能走的更远，飞的更高，看的更广；
别忘了来时的方向。

之前的文章说了 memcached源码学习-线程框架 和 get操作处理代码， 其实最重要的是他的缓存过期策略，以及内存管理机制， 篇幅过长分几篇文章写，这里写一下memcached的缓存过期策略。

说到缓存过期策略，网上有一大堆帖子会介绍说“LRU, 最近最少使用 ” 算法，而且源码中间也是大量的含lru字样的函数，变量，比如lru_crawler_crawl 等，很多人也就信了，可事实却不是这样的。 阅读全文...

1.4.20 版本在处理 lru_crawler crawl 2 指令的时候，lru_crawler_crawl函数竟然存在变量未定义的bug，从而导致错误的清理了不应该的slabs槽位的数据。
阅读全文...

前阵子高峰期看线上日志，偶然发现了核心数据库mysql出现大量死锁， show engine innodb status 日志如下：（为了保密，部分字段已移除） 阅读全文...

小事，但不断的被打扰，忍不住写下来。

写代码的人都知道做事情要学会并行，不断的处理不时而来的中断，比如同事问你问题，朋友聊天等，但由于对方经常打字不够快，你发一条消息过去后，对方很可能得好几十秒，几分钟才能回复过来，所以中间肯定不能盯着聊天框等对方答复，于是需要去做其他事情，比如写代码。
这本来很正常的事情，却被一群“在吗？”党给搅和的实在郁闷，经常一个小事情，一句话留言说清楚了，非得一来一回好几条消息，还间隔好几十秒，把你的时间打的七零八碎的，苍天·······
以后面对这种人，直接不回复 或 发送RST包！！！ 阅读全文...