Paxos Made Simple 读后感

近来在Cousera上学习 Cloud Computing Concept Part 1，其中涉及到了对Paxos算法的介绍。Paxos算法固然是比较难懂的，但是幸好有简化版论文 Paxos Made Simple，相对好理解很多，分享一下自己的理解。

Paxos算法的问题背景

分布式系统进程模型：多个分布式进程节点，彼此只能通过网络消息通信；整个系统是异步的，时钟可能不同步，时间流速也可能不同，消息可能丢失，乱序到达，也可能无限延迟，任一进程可能失败退出（但是至少超过半数节点存活并可以互相通信）。

分布式一致性问题：分布式系统中每个进程都有一个变量y，最初处于为未初始化状态，一旦变量y的值被确定，就不允许被修改；经过有限步骤，使得所有活着的进程都确定同一个y值，这就是一致性问题

Gossip协议是一个在大规模分布式系统中被广泛使用的信息交换协议，用于解决应用层的多播问题。

最近在学习Cousera上的Cloud-Computing-Concepts课程，里面布置了一套基于Gossip的成员协议的编程题，花了一天时间写完代码与调试，记录一下读后感与体会。

Gossip 理论

如何在一个大规模分布系统中高效传播一个信息？

最简单的办法是向集群中的每个节点发送一条消息，但是随着系统规模的增大，考虑到网络的丢包与延迟以及防火墙之类的特殊构造，这个方法不能确保每个节点都能得到最新消息，源节点的传播耗时与网络负载也过高。

Golang HTTP 客户端连接池的性能问题

前一阵子使用Golang在开发一个微服务，通过HTTP协议与其他依赖模块交互。当时测试时遇到了一个性能问题，现在记录一下，以做备忘。

问题模型

服务端代码：

Alibaba/Druid 无限次重试报错并阻塞业务线程

Alibaba/Druid 是一个广受欢迎的开源数据库连接池组件。但是，由于配置不当，也会对服务稳定性产生负面影响。

我们的某个服务提供了一个功能，可以帮助用户随机预览给定数据源上的表数据。但是，当用户提供了错误的IP/Port信息，或者错误的授权信息，或者错误的数据库协议的时候，服务接口未能及时响应，最后网关报504超时，影响用户体验。

查看日志

为了优化这个环节，我们先查看了应用的异常日志，发现应用仍然在不断的抛出连接失败的异常，并且，抛出异常的线程不是HTTP Worker线程，而是名为Druid-ConnectionPool-Create-XXX的线程。详细如下：

First Commit