在项目中经常遇到双向通信的场景，如指令的实时下发、状态的上报等，这时候使用 HTTP 协议就有点捉襟见肘。正常情况下一般会使用 TCP/Websocket 协议来实现，不过不同于 HTTP 协议简单及有大量框架的支持，使用 TCP/Websocket 需要考虑心跳、协议的定义、数据的序列化（反序列化）及 RPC 调用的实现。相对来说，入门相对比较复杂。 如果能有一个项目能够对上述功能进行封装，隐藏不同协议之间的差异，对上层应用提供一套统一的接口，上层业务只关心业务，那么就会减少开发人员的学习成本，快速接入项目。 Alligator 项目就是为了解决上述的场景而开发的，它提供了一个框架，可以让开发人员快速进行 TCP/Websocket 及 HTTP 的开发，而无需关心下层使用的协议。在此基础上，Alligator 还提供了一个进行长连接网关开发的脚手架，它是业务无关的，可以快速接入不同的业务场景。
之前买了一台阿里云的云主机，一直想把用起来。考虑到我的个人网站之前部署在 github 上，网页加载比较慢，正好可以用云主机进行部署，提升速度，开始操作。
这篇文章是学习刘超老师在“极客时间”的课程《趣谈网络协议》之后，做的一个总结。
这篇文章主要是记录一些生活或工作中基本原则，方便后续查看及思考。
在 Mysql 中，存储有三种日志，分别是 binlog log、undo log及 redo
log，其中 binlog 日志由 Mysql Server
生成，用来记录对数据库的更新操作，使用场景有主从同步及数据恢复；undo
log及 redo log由 Innodb
存储引擎生成，用于保障事务进行。undo日志用于事务的回滚及MVCC，实现事务的原子性，而
redo log基于 WAL（ Write-Ahead Logging）
技术，存储事务过程中对数据表的修改，主要是数据页的修改，保证了事务的持久性。这三种日志在数据库表的更新操作（包括新增、修改及删除）中，相互配合，保障了事务的顺利执行，下图以一次数据更新操作演示了它们的工作机制。
在一致性算法中，Raft 及 Paxos 是强一致性的算法，属于 CP（一致性及分区容错性） 的使用场景，为了保证算法的准确性，必须保证大部分节点（服务器）是正常的（三个节点容忍一个节点失败）。但在 AP （可用性及分区容错性）场景中，即使只有少数机器的存在，仍然可以对外提供服务，这些场景包括：失败检测、路由同步、Pub/Sub 及动态负载均衡。而 Gossip 协议就是这样一种支持最终一致性算法的协议。
在分布式系统中，一个核心的问题就是解决数据一致性的问题，即共识问题（多副本共识问题）：
Consensus Problem : Requires agreement among a number of processes (or agents) for a single data value.
共识问题简单来说，就是多个进程（代理）就某个单值达成一致，主要的应用场景数据多副本的复制。而
Paxos 及 Raft
算法的提出便是为了解决共识问题，它们在工程实现上得到了广泛的应用，如
Goggle 的 Chubby、Apache 的 ZooKeeper 及 Raft算法实现
Etcd。这些算法都可以统称为一致性算法。 
一致性算法大概可以分为4个类型：
这篇文章就四种类型的算法进行一个概要的分析，更多的是逻辑概念层面，不会对细节及实现过多讨论，那也超出本人的认知。
这篇文章主要讲述 select 和 epoll 的实现原理，包括底层的数据结构、与设备的回调处理机制及两种实现之间的差异。
这篇文章讲述网络报文从网卡 NIC （network interface controller）接收，再到操作系统网络协议栈处理，最后到用户程序接收报文处理报文的简化过程，希望能对TCP协议进行一个整体、概括性的总结。
在 垃圾回收之回收算法 这篇文章中预设了两个前提： 1. 根集合及对象中的指针集合已经得到； 2. 堆是可遍历的，即从一个对象可直接定位到下一个对象；
为了描述的方便，在上篇文章中直接得出了结论，而这篇文章的目的就是解释这两个问题。