Google的三篇论文影响了很多很多人，也影响了很多很多系统。这三篇论文一直是分布式领域传阅的经典。根据MapReduce，于是我们有了Hadoop；根据GFS，于是我们有了HDFS；根据BigTable，于是我们有了HBase。而在这三篇论文里都提及Google的一个lock service—Chubby，哦，于是我们有了Zookeeper。
Zookeeper可以干什么
在Zookeeper的官网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
这大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服务，提供分布式同步以及集群管理。那这些服务又到底是什么呢？我们为什么需要这样的服务？我们又为什么要使用Zookeeper来实现呢，使用Zookeeper有什么优势？接下来我会挨个介绍这些到底是什么，以及有哪些开源系统中使用了。
ZooKeeper之ZAB协议
ZooKeeper为高可用的一致性协调框架，自然的ZooKeeper也有着一致性算法的实现，ZooKeeper使用的是ZAB协议作为数据一致性的算法， ZAB（ZooKeeper Atomic Broadcast ） 全称为：原子消息广播协议；ZAB可以说是在Paxos(帕克索斯)算法基础上进行了扩展改造而来的，ZAB协议设计了支持崩溃恢复，ZooKeeper使用单一主进程Leader用于处理客户端所有事务请求，采用ZAB协议将服务器数状态以事务形式广播到所有Follower上；由于事务间可能存在着依赖关系，ZAB协议保证Leader广播的变更序列被顺序的处理，：一个状态被处理那么它所依赖的状态也已经提前被处理；ZAB协议支持的崩溃恢复可以保证在Leader进程崩溃的时候可以重新选出Leader并且保证数据的完整性；
什么时候需要自己搭建缓存服务
都说“程序等于数据结构加算法”，在软件的运行时刻，其实是数据加进程，进程离数据越“近”，越能得到高速的读写性能。
软件服务内部的多线程模型
回顾之前说过的，服务和服务之间的调用，可以分为同步调用（发起方等待结果）和异步调用（发起方不等待结果），同步调用的好处是写代码简单，坏处是有可能阻塞线程，造成线程资源浪费。我这里说“有可能”，是因为可以使用支持io异步的编程语言，来避免线程阻塞。
一种可扩展缓存架构
之前对于并发和异步讲得比较多，今天讲一下更常见的缓存应用架构。
我们先看一个简单的架构
zookeeper在分布式应用中的作用［转］
是不是要在标题的“作用”之前加上“重要”两个字，我犹豫了一下，zookeeper提供的功能是如此的重要，以至于如果你在应用中不使用它，早晚也会在你的应用中去实现zookeeper 的功能，所以，zookeeper值得你花（一点）时间去掌握。
Zookeeper的安装
RabbitMQ中的cluster的架构
今天对 RabbitMQ的cluster做个了结，感觉要学习的东西太多了，日后如果使用到了rabbit时，再来回顾吧。
RabbitMQ的cluster在普通模式下（注意是默认模式），吞吐大概在2w左右，但这种的模式不太实用，只要主节点一旦挂掉，整个集群就无法使用，这里不做过多的讨论。主要讨论它的镜像模式，这种模式需要设置vhost的策略（policy）
RabbitMQ中的权限控制
在刚开始看RabbitMq权限的时候，分不清楚角色和权限（permission）的区别和用法，今天把我对它们的理解做一个总结。
RabbitMQ中的运维命令
之前在学习RabbitMQ原理的时候，觉得RabbitMQ的启动、停止命令好坑，还有app_start、app_stop，到底用哪个启动呀？有什么区别和联系吗？本人在学习官方教程的过程中，做了这篇笔记。
Nginx中根据路径反向代理
今天在配置nginx的时，碰到的一个问题。
RabbitMQ的PHP教程之RPC (六)
RPC（Remote Procedure Call Protocol）远程过程调用协议，简称远程调用。但如果仅仅从这一层意义上来说，RabbitMQ的PRC没有实际的意义，因为远程调用接口服务，我们通过curl会更简单易用一些，而且PHP本身也有RPC调用的相关方法。但我要说的是，RabbitMQ的RPC主要用于消息消费后的回复。在这一点RabbitMQ就显得有意义了。因为我们有的时候，发送消息后，需要知道消费的情况，根据消费的情况做后续的逻辑。
RabbitMQ的PHP教程之topic (五)
学习完了RabbitMQ的PHP教程之Routing (四)，route的核心思想就是告诉我们，queue是可以绑定多少routeKey，同时接收多个routeKey的消息，在文章的末尾，我也总结exchange、routeKey、queue、message之间的对应关系 。在文中有以下几行代码：
RabbitMQ的PHP教程之Routing (四)
关于这一篇的教程，主要是针对Route Key的使用。在第二篇的文章中，我们使用direct类型的exchange实现工作队列。在这个基础之上，我们再进行一个扩展：即一个队列绑定多个route key，这样绑定多个route key的队列就能接收到不同route key的消息。但有一点是固定不变的，就是一个message只能有一个route key.
继续阅读
RabbitMQ的PHP教程之发布/订阅 (三)
发布 ／ 订阅模式可以理解为广播模式：即exchange会将消息转发到所有绑定到这个exchange的队列上。针对这种广播模式，RabbitMQ增加了exchange Type的选项 AMQP_EX_TYPE_FANOUT，这种类型在发送消息，queue bind时，都将忽略route key，也就是说不需要设置 route key。
RabbitMQ的PHP教程之工作队列 (二)
在上一篇文章中，简单实现了消息的发送与接受（参考：RabbitMQ的PHP教程之入门 (一)），但在实际的应用中，很少会使用，本人也不建议使用，因为这种隐藏式的申明，很容易给人造成困扰。但它展示了RabbitMQ的工作原理。
RabbitMQ的PHP教程之入门 (一)
从网上也看了一些关于RabbitMQ的翻译版的教程，觉得有点啰嗦了。所以基于官方
http://www.rabbitmq.com/tutorials/tutorial-one-php.html做一个简单的备注说明，同时也是本人对学习RabbitMQ的一个总结。本人是从事PHP开发的，所以教程中的代码，都是使用PHP来实现，同时丢弃官网使用composer中的AMQPLIB，因为这个AMQPLIB对一些方法进行了封装，不只直观，所以本人使用原生的类、方法进行备注说明，这样更易于理解过程。
RabbitMQ AMQP 消息模型攻略
AMQP 的消息模型如下图所示:
通过此图我们可以知道, 一个消息的发送流程有如下几个步骤:
- 消息生产者将消息发布(Publish)到 Exchange 中.
- Exchange 根据队列的绑定关系将消息分发到不同的 Queue 中.
- AMQP broker 根据订阅规则将消息发送给消费者 或 消费者自行根据需要从消息队列中获取消息.
AMQP文件中的常量
/**
* Passing in this constant as a flag will forcefully disable all other flags.
* Use this if you want to temporarily disable the amqp.auto_ack ini setting.
* 传递这个参数作为标志将完全禁用其他标志,如果你想临时禁用amqp.auto_ack设置起效
*/