本文原创部分占比不多，图片多是盗用，不知道最开始是谁画的，我是从http://geek.csdn.net/news/detail/67260取的。此文主要是做一个自己的梳理。
TCP的每个数据包大小不能超过MSS值，在发送端超过的，需按照MSS进行分段(segment)。
分段这事情，老是让CPU来做，那是很耗精力的事，做网卡的乐意分享此任务，将其offload到网卡，当网卡支持TCP分段这功能的时候，我们就说它支持TSO(TCP segmentation offload)。
继续阅读
网络数据传输，底层是物理设备的支持，如路由、交换、网卡、网线，通过网线传送电信号或者光信号，自然可以"连续"地传输，但是，考虑到连续传输，如果中间某个信号被干扰，一个bit不正确会导致整个串都不正确，损失颇大；其次，考虑到线路的多源共享问题，如果一直传送一个源的数据，其他的数据就得不到发送。于是，聪明的设计者将来自一个源的大段数据，拆分成小段，如果某一小段传输不正确，只影响这一小段，而非整体，根据一定的算法交替发送不同来源的数据，可实现线路共享，而分割的这一小段也就是我们说的帧(Frame)，帧也称为协议数据单元(PDU)。
继续阅读
编译代码，我喜欢操纵感强的，jenkins更适合构建，而不适合自己捣腾。
以前我们用虚拟机初始化一个环境，然后chroot，挺好，但是时常出现资源不够用的情况（很多人在一台HCI上创建虚拟机，不卡才怪），QEMU+KVM虚拟化的坏处是资源消耗太大，所以，用docker这种天生无太多牵挂的东西，性能会提高很多，而且更灵活（派生一个虚拟机和pull一个docker，感觉完全不同）。
继续阅读
写了一段脚本，如果系统有flock命令，就用flock来加锁，否则用ps来查看是否已经有本进程在运行，以保障其单例性。 继续阅读
结合《七种武器设计篇之设计是自找的》看，前面设计了一个Python调用命令行的封装，我一般在自测上做很多功夫，所以，幸与不幸，还是测试出了问题。 继续阅读
一直有个悖论，如果一个人，没有设计能力，那就不会给你模块设计；但是，一个人的设计能力，需要从实际的设计中锻炼出来，如果不给你模块锻炼，如何得来设计能力？
看样子是这样的，但是，也不尽然，我之前给同事吹过牛逼：设计，是自找的。
你可以从每天改BUG的生活中，找到设计，之前举了一个我在改BUG的时候如何为HCI引入redis的例子，我今天看一下，一个普通的API，如何自找设计。 继续阅读
galera cluster是一个MySQL的多主高可用方案，相对于异步复制，最大的长处是不丢数据，因为他是同步复制。
因为aCloud原有实现就是基于半同步机制的，所以我们讲了《MySQL Semi-Synchronous Replication》，明白了半同步机制，我们再来看看目前在复制机制下的高可用实现。
为了实现HA（High Availability，高可用），引入了VIP（Virtual IP，虚拟IP）。
在master/slave的复制模型下，master对外提供写服务，slave可以不提供任何服务，只是做备份。
也有人将slave利用起来，提供读服务，就叫做读写分离，读写分离可以减轻单台服务器的压力。
不管怎么说，半同步机制是单master多slave的模式，这种模式下，只能在master上提供写服务，如果master挂了，如何保证业务连续性？
VIP原理类似DNS，在DNS中我们每次链接到一个域名，每次解析域名得到可提供服务的IP。VIP的话，我们每次在能提供服务的主机上，配置一个固有IP，如果这台主机出问题了，例如宕机了，就在其他能提供服务的节点，例如从节点配置该IP，这样用户每次链接同一个IP，也能实现高可用。 继续阅读
半同步复制(Semi-Synchronous Replication)是相对于同步复制和异步复制而言的折中方案，当两台MySQL数据库需要同步数据，基本的复制思路如图：
master对外提供写服务，并开启binary log功能，然后slave节点启动一个IO线程来从master的binary log同步并将其写入本节点的relay log中，slave再启动一个SQL线程，从relay log中读取日志记录并插入本节点的数据库。
一切原理都是那么简单。 继续阅读
linux API提供int daemon(int nochdir, int noclose)函数，功能相对简单，有的地方考虑并不周全，比如文件描述符继承且没有close，raf@raf.org的http://libslack.org/ 里有daemon的实现（也是shell里面daemon命令的源码），逻辑严谨，注释清晰，先欣赏一下他的源码，如果能看明白，这篇文章就不用看了，如果看不明白，请继续。 继续阅读