LeeYzero的博客

周末大清早就被报警短信吵醒，故障表现为离线存储集群流量突增，集中在热点分片，而且流量越来越大，系统吞吐、稳定性均在降低。最终发现是因为实例间时区不一致触发一个隐藏的BUG导致。这个问题在分布式系统中很具有代表性，在此做个记录以备忘。

症状

• 离线存储集群流量突增，集中在热点分片；
• 消息系统中消息在持续积压；
• 消息系统收到大量重复ACK；
• 业务worker消费到大量重复的消息；

RAII作为C++资源管理的一种惯用法，是每一位C++程序员都应该掌握的基本技能。在google上搜索关键字RAII, 有二百多万条搜索结果。说明这个话题在网上已经被讨论过无数次，也发现了一些好文章给我不少启发，这篇文章主要是做个总结并谈谈自己的理解。

什么是RAII

资源获取即初始化（Resource Acquisition Is Initialization），即RAII。RAII是一种C++编程技术。它利用栈对象在离开作用域后自动析构的语言特点，将受限资源的生命周期绑定到该对象上，当对象析构时以达到自动释放资源的目的。 这里说的资源都是指的受限资源，比如堆上分配的内存、文件句柄、线程、数据库连接、网络连接等。

在计算机中，锁是用于解决资源竞争问题。在单机（单进程）环境下, 锁可以使用操作系统提供的同步原语实现。 但在分布式环境下，操作系统提供的同步原语就失效了, 需要一个分布式锁。其原理是需要一个分布式锁管理器[1]，提供进程级别访问共享资源的互斥性。本文主要讨论基于Redis实现的分布式锁。

分布式锁的使用场景

Martin Kleppmann 在他的博客 How to do distributed locking[2] 中对分布式锁的使用场景做了非常好的概括。从一个更高层次来讲，在一个分布式应用中，使用分布式锁主要有两个原因：效率和正确性。

• 效率：获取分布式锁可以避免相同的任务被处理两次。如果锁失败，带来的结果就是对某一个子任务多做了一次，其影响完全取决于具体业务场景。比如为了提高消息PUSH效率，需要按用户进行分片，然后每个任务获取一个锁后处理对应的分片，如果锁失败，会造成重复给用户PUSH。
• 正确性：获取分布式锁是为了防止进程对分布式系统中的资源并发访问而导致系统的状态出现混乱。如果锁失败，两个节点并发的访问同一个共享资源，可能造成数据的不一致性，如文件损坏或数据丢失等。

make是一个自动化构建工具，广泛应用于Unix及其类Unix系统中。make最先应用于编译C语言项目，不仅如此，只要某个文件发生变化就需要重新构建的项目都可以使用make工具进行构建。

Makefile是可以被make解析的特定格式的文本文件。其语法简单，当我们构建一个程序时，其工作原理大致为：make首先解析Makefile，查找构建应用的一系列依赖，并检查每个依赖文件是否过期（是否发生变化），如果发生过期，即重新构建变化的依赖文件。

最近工作中使用Go开发比较多，而大部分工作都是使用vim完成，在配置vim的Go环境时，发现已经有很多现成的插件可用，对我而言，主要配置以下四个插件就够用了：

• vim-go: go语言的vim插件。支持代码格式化、语法检查、语法高亮、调试等非常多的功能。
• tagbar: 用于方便查看代码结构。
• nerdtree: 用于管理和查看代码目录结构。
• YouCompleteMe: 用于代码自动补全。

依赖环境

安装go环境

参考go官网，按步骤安装，配置好GOROOT和GOPATH环境变更即可，配置go的vim IDE环境需要依赖vim和vim-go插件。

vim-go插件需要vim使用8.0以上的版本，而YouCompleteMe需要python2.7.1+或3.5.1+。如果你系统的vim和python版本满足条件，可以忽略下面两个步骤。

相对于IDE，vim的学习成本较高，但一旦熟悉vim后，开发效率是非常高的。vim的命令非常多，但在工作中常用的却比较少，本着实用主义，参考Learn Vim Progressively，整理最有用的命令，也便自己以后查阅。下面涉及到ctrl键的组合操作，如ctrl和r组合，用<C-r>表示

模式

vim有三种模式：普通（normal）模式、插入（insert）模式和命令（command）模式。刚进入vim时默认进入普通模式，下面看下各模式的转换：

普通模式下键入i进行插入模式
普通模式下键入:进入命令模式
按ESC退出插入模式和命令模式

vim的文档非常全，在命令模式下，我们可以键入h或help打开帮忙文档，也可以直接键入help <command>，查看指定命令的帮助文档，如help i。

在普通模式下通过hjkl(左下上右)移动光标，插入模式下可以键入任意字符，命令模式下可以输入命令，回车键执行命令。如何退出呢，进入命令模式，键入q就可以退出了，如果有更新会提示你保存，键入w进行保存。也可以同时键入wq保存退出。

最近花了一个周的零星时间，看了《编写可读代码艺术》，收获颇多。虽然平时也经常使用书中提到的一些方法编写代码，但只是一种直观感觉认为这种方式是“正确”的。书中将这些方法提炼成一条条原则，并采用大量实例佐证这些原则。书中系统化的介绍了如何编写可读代码，并提出很多指导性原则，整本书不到200页，非常值得阅读。

基本原则

何为好代码，何为坏代码，每个人的判断标准可能并不一样，但作者提了总的指导原则：代码应当易于理解来诠释什么是好的代码，并用可读性基本定理：代码的写法应当全人理解它所需的时间最小化来衡量代码的可理解程度。即“可读”是一个总的指导原则，而可读性基本定理则是对“可读”的定量判断。当我们在犹豫不决时，可读性基本定理可以帮你做判断。

命名

在编写代码时，做的最多的一件事情就是命名，我们会对变量、函数、类、包等命名，命名的本质是把信息封装到名字中，好的命名，可以帮忙你快速理解代码。书中提到了很多指导原则，我认为比较重要有些原则的如下：

这个星期利用上下班时间，读了一下《如何阅读》，书只有200页左右，很快就能读完。之所有写这篇读书笔记，一是实践书中的一些方法，训练自己归纳总结的能力；二是希望自己养成做读书笔记的习惯。以下是自己读完这本书的一些感想，我尝试用三个问题来对整本书进行总结。

为什么要读这本书

明确自己的阅读目的非常重要！这可能跟学生时代学习课本知识不同，学习时代学习的课本都是系统化构建好的知识体系，我们没有多少选择。但当你想挑选一本书进行阅读时，可选择的书就太多了，如果不明确为什么要读一本书，那么读完后只是短暂地存储于你的大脑中，很快就会忘记。

一本书的信息量可能是非常大的，当自己带有目的性去阅读时，这就好比划重点，会着重关注自己比较在意的内容。这个时候跟作者就会有对话，你急需想通过书中的内容解答你的疑问，会加深对书中内容的理解。

比如我读《如何阅读》这本书时，就带有很明确的目的，我想通过这本书回答我以下两个问题。

• 如何提升阅读速度
• 为什么读完一本书很快就忘了

在mac环境下，我们经常会使用iTerm2终端连接远程服务器，也经常会有本机和远程服务器之间进行文件共享的需求。这个时候lrzsz就派上用场了。

lrzsz是unix下的开源软件包，支持XMODEM, YMODEM ZMODEM文件传输协议。本文将会展示如何将lrzsz集成到iTerm2终端中，通过sz和rz命令和远程服务器传输文件。 其中，s表示send，r表示recieve，z表示使用的协议为ZMODEM。

对于传统Win32界面编程来讲，微软提供一整套界面标准，比如窗口、按钮、滚动条、列表等。对于每一个窗口（控件也是一个窗口），其能响应的消息和行为都有规范（通过API提供给开发者）。微软这套界面标准是为通用场景下提出的解决方案，能够满足绝大部分需求，但业务场景的多样性，使得开发者们并不满足于这套界面标准。

DirectUI的发展历史

• 2005年6月，Bjarke Viksoe发布了一篇文章UI: Become windowless, 阐述了无窗口句柄（windowless）思想。
• 2010年12月，金山网络宣布启动金山卫士开源计划，该开源项目以失败告终，但有热心的网友从该项目中分离了金山卫士的界面部分成为一个独立的项目bkwin。
• 2012年之后，由bkwin项目衍生出各种基于DirectUI思想的开源框架，如Duilib、DuiEngine、DuiVision、SOUI等。

什么是DirectUI

DirectUI是一种界面开发思想。其核心思想是指将所有的界面控件都绘制在一个窗口上，这些控件的逻辑和绘制方式都必须自己进行编写和封装，而不是使用Windows的原生控件，所以这些控件都是无句柄的（Windowsless）。

那这个名称是怎么来的呢？由于Windows有句柄窗口是一套工业标准，窗口消息和API都是公开的，所有人都知道怎么操作窗口。微软在做MSN的时候为了保护用户隐私，搞了一个DirectUIHWND，后边DirectUI这个名字就被沿用下来，后边说的DirectUI一般都是指无句柄窗口。