riak_admin只是一个bash脚本，当riak_admin join被执行时，都是在执行riak_kv_console join。

大概过程分析
riak_kv_console:join => %%入口
riak:Join(Node) => %% 真正执行
riak_core:join(Node) => %%去到riak_core
riak_core_gossip:legacy_gossip() => %%通知检查是否是 legacy gossip，
riak_core:standard_join(Node,Ring,false) => %%非rejoin 非legacy
riak_core_gossip:send_ring(Node, node()) => %% 进入gossip模块发起ring请求
gen_server:cast({?MODULE, FromNode}, {send_ring_to, ToNode}) => %%广而告之
riak_core_gossip:handle_cast({send_ring_to, Node}, State) => %%收到
gen_server:cast({?MODULE, Node}, {reconcile_ring, RingOut}) => %%告诉它们开始协调
riak_core_gossip:handle_cast({reconcile_ring, RingIn}, State) => %%收到
riak_core_ring_manager:ring_trans(fun reconcile/2, [OtherRing]) => %%由一个协调函数传入到ring manager中去执行
riak_core_ring_manager:prune_write_notify_ring => %%搞定一个新的ring文件，通知所有的listener
riak_core_ring_events:ring_update(Ring) => %%通过event通知
riak_core_ring_handler:handle_event({ring_update, Ring}, State) => %%接到event
riak_core_vnode_manager:ring_changed(Ring) => %%vnode_manager通知大家环修改了
riak_core_vnode_manager:trigger_ownership_handoff(?MODULE, {ring_changed, Ring}) =>%%接通知触发handoff
riak_core_vnode:trigger_handoff(Pid, TargetNode) => %%由vnode来干活
gen_fsm:send_all_state_event(VNode, {trigger_handoff, TargetNode}) => %%使用gen_fsm来通知vnode们
riak_core_vnode:maybe_handoff => %%准备开始导数据
riak_core_vnode:start_handoff => %%开始
riak_core_handoff_manager:add_outbound => %%发handoff
handle_call({add_outbound,Mod,Idx,Node,Pid},_From,State=#state{handoffs=HS}) => %%收到请求
riak_core_handoff_manager:send_handoff => %%发
riak_core_handoff_sender_sup:start_sender => %%启动sender 最终启动了 riak_core_vnode_master:sync_command直到同步结束。

riak_core_vnode:mark_handoff_complete
此代码生存在riak_core_vnode，而不是riak_core_vnode_manager，因为ring_trans是一个同步的call到ring manager的过程，block一个单独的vnode要比block整个vnode manager要好。block这个manager会影响所有的vnode。此代码对多个并行的vnode执行是安全
的,因为靠单个 ring manager提供的同步化保证了拥有所有的环的变更经过 。

riak_core_vnode:vnode_command
活动的vnode运行于三种状态中：正常、handoff、推进。
在正常状态，vnode命令靠handle_command来传递。当一个handoff被触发，handoff_node被设置为目标节点，并且这个vnode被称做进入了handoff状态。
在handoff状态，vnode命令依靠handle_handoff_command来传递。即使handoff程序是非block的（比如在riak_kv中没有使用async fold时），在handoff期间，一个vnode也会被block住（所以没有服务命令）。
handoff状态之后，一个vnode会进入到推进状态。推进状态是新的gossip/membership代码的产物，并且legacy模式的节点里不会出现。推进状态代表了vnode已经传递自己数据到新节点的情况，但新的节点并未在环上列出当前节点的信息。这会出现是因为增加的vnode仍然在等handoff他们的数据给新的拥有者，或者只是因为环还汇聚在这个新节点之上。在推进状态，所有的vnode指令和coverage命令都会按过程推给新的拥有者。

riak_core_vnode:start_manager_event_timer
独有的vnode进程与vnode manager结合紧密。当vnode的事件触发，这个vnode必须确保这个事件被发送到vnode manager，这将会产生一个状态变化的决定，并且发回适当的信息给这个vnode。为了最大限度地减少阻塞，使用了异步的消息。vnode manager挂掉而丢失靠vnode发送的信息是可能的。因此，vnode周期性地重发事件消息，直到一个从vnode manager来的合适的消息被接收。

安装
机器环境
centos 5.5 64位机器

有两种编译器，官方的文档是基于Go编译器和工具（6g 8g），另一个是gccgo（后台是gcc）。
工具和编译的对照表：

amd64 (a.k.a. x86-64); 6g,6l,6c,6a
386 (a.k.a. x86 or x86-32); 8g,8l,8c,8a
arm (a.k.a. ARM); 5g,5l,5c,5a

这是一个坑：Mercurial（hg工具）需要安装，并且要1.7版本以上的。（实际上给个下载的tar包不是可以降低门槛嘛，应该是还在开发状态为了方便使用hg直接升级环境）。折腾这个的人应该不在少数。

hg clone -u release https://go.googlecode.com/hg/ go

cd go/src
./all.bash

最后会停在一段时间：

--- cd ../test

然后提示：

0 known bugs; 0 unexpected bugs

ALL TESTS PASSED

---
Installed Go for linux/amd64 in /root/go.
Installed commands in /root/go/bin.
*** You need to add /root/go/bin to your $PATH. ***
The compiler is 6g.

就表示编译成功了。

添加到PATH环境变量

vim /etc/profile
PATH=$PATH:/root/go/bin/
export PATH

source /etc/profile

安装完毕。

跑一个hello word:

$ cat >hello.go < package main

import "fmt"

func main() {
fmt.Printf("hello, world\n")
}
EOF
$ 6g hello.go
$ 6l hello.6
$ ./6.out
hello, world
$

什么是riak_core?
riak_core是一个单独的OTP应用，提供了所有必须的服务，以完成一个现代化的、表现良好的分布式应用。riak_core开始于Riak的一部分。当代码在建立各种分布式应用普遍有用时，我们决定重构并且分离出来核心部分，使其便于使用。
分布式系统是复杂的，riak_core可以满足这些大量复杂的需求。在深入代码之前，我将分离这些需求为明显的分类，且给出每项的概况。
注：如果你是急性子，想跳过后面的直接读代码，你可以通过hg或者git检出riak_core的代码。

节点存活 & 节点关系
riak_core_node_watcher是负责反馈riak_core_cluster内部节点状态的进程。它使用net_kernel有效地监控了许多节点。riak_core_node_watcher也有能力将一个节点按程序预定踢出cluster。当一个主节点必须临时断电而又不想完全停服的情况，这十分有用。
riak_core_node_watcher还提供了在cluster内广播和定向服务的API。当节点提供了专门的服务，比如CUDA计算节点，这个服务被cluster中的其他的节点所使用，这些API很有用。
riak_core_node_watch_events配合riak_core_node_watcher产生以活跃节点为基础的events，比如说加入或者离开cluster等等。当事人可以注册callback方法，当events被触发时会被调到。

分区 & 分布式工作
riak_core在每个节点上使用了master/worker配置，以管理工作单元的执行。一致性哈希被使用来决定哪一个目标节点用来发起请求，而且主进程在每个节点的farms公开对实际workers的请求。riak_core把工作进程叫做vnodes。相应的进程叫vnode_master。
在需要的时候，在riak_core里的分区和分布的逻辑同时掌控了hinted handoff。hinted handoff发生在一个节点失灵或者断电时。为了确保可用性，许多集群系统会使用可用节点代替挂掉的节点。当挂掉的节点恢复，集群需要从它代替节点的临时空间迁移数据去恢复节点的永久空间。这个进程被叫做hinted handoff，并且被riak_core里的组件管理。riak_core也掌控了迁移分区去新节点，当它加入到集群，集群能够持续地工作，并且平等地分给集群中所有成员。
riak_core_vnode_master在一个给定的节点启动所有的工作vnodes，并且当集群启动的时候把请求路由到vnodes。
riak_core_vnode是一个OTP behavior包装，所有的样板逻辑需要实现一个vnode。特殊的应用vnodes必须实现少量的回调函数，以参与handoff的session并且从master接收工作单元。

集群状态
一个riak_core集群保存了在一个环状结构上的全局状态。这个状态信息在集群中的节点间传输，以一个可控的方法保证所有的集群成员同步。这个进程被叫做“gossiping”。
riak_core_ring是用来创建和控制环的状态信息的，并且会与集群中的所有节点共享。环状态信息包括像分区关系、特定集群环上的元数据等元素。比如Raik KV存储把桶的元数据保存在环元数据中。
riak_core_ring_manager帮助一个节点管理集群环信息。它是应用代码访问环的主入口点（通过riak_core_ring_manager:get_my_ring/1），并且还能保存从当前环的状态同步过来的环持久快照。
riak_core_gossip管理环的gossip进程，它要确保环在整个集群里全都一致。

下一步计划
下面的几个月之后，我们将在这博客一系列的日志里覆盖建立一个真正的应用步骤，每篇都将覆盖使用riak_core建立某种系统。所有应用代码都将在apache2声明下共享到github。
那我们要建立哪种类型的应用？因为这个系列的目标是为了举例如何使用riak_core建立一个分布式系统，同时也是为了满足我自己的技术好奇心，我决定建立一个分布式图片数据库。为了真正练习riak_core，一个图形库应该提供足够的用例，与此同时，不能把核心学习体验搞得十分复杂。
感谢Sean Cribbs和Andy Gross提供有用的review和feedback。

[from http://basho.com/blog/technical/2010/07/30/introducing-riak-core/]

使用maven，nexus是个不错的选择。
最常见的问题：

1.SNAPSHOT拿不到最新的包。
2.明明在maven central库里搜索到的包，却提示Missing。
3.plugin提示Missing。

1.SNAPSHOT拿不到最新的包。
这个问题往往得nexus+hudson造成的。因为daily build导致与日俱增的jar包堆积在一个文件夹下，文件数目过多，导致在取最新的包时超时了。
解决办法：
浏览器打开nexus， login->scheduled tasks->add，添加一个定时清理目录的计划任务即可。最后一个选项“remove if released”需要慎重，平时开发可能不是特别正规的时候可能会snapshot和release都需要。

2.明明在maven central库里搜索到的包，却提示Missing。
网上大多数说法都是index失败了，个人经验实际不然(当然不排除你的问题就是index失败)。
当nexus.log里没有任何异常时，请注意以下内容：
在central搜索时，如果只有pom没有jar，那说明这个依赖的项目可能有多个依赖，一定要加上pom，默认是jar。

3.plugin提示Missing。
通常原因是：nexus设置的搜索顺序有问题。
login->Public Repositories -> configuration
左边的是正在使用的定义好的仓库组，右边是可以使用的，正确的顺序应该是先在Release找，然后Snapshots，然后3rd party，最后才去外网下（这时nexus才拖下来新的jar/pom）。

接入层
是指普通用户与核心业务逻辑中间的过程。现在常见的服务接入层，像nginx、lvs、php这些都可以算是。

观点
一种观点认为：接入的量不应该影响系统的正常运行，也就是不能接入不能处理的用户请求，类似上图中前图。
另一种观点认为：接入层应该尽量接入所有用户，类似上图中后图。

做法
nginx：
nginx如果用做proxy，后端挂其他服务的话，是一个纯粹的NIO server。对用户来说，nginx是长连接（http 1.1），对后端服务来说，nginx是短连接（http 1.0）。

default: proxy_connect_timeout 60s; 向后端服务创建连接的超时时间
default: proxy_read_timeout 60s; 后端返回请求响应超时时间
default: proxy_send_timeout 60s; 大请求发到后端超时时间

nginx通过上面的三个设置，当后端有响应不过来的时候，进行超时处理（记录日志），当发现超时很多了，就需要提升后端的处理能力了。

那么，nginx自身的处理能力是否有上限呢？当然有!

worker_processes 1;
worker_connections 1024;

max_clients = worker_processes * worker_connections

当超过max_clients的用户扑上来的时候，如果幸运后端没有能力问题，那就会看到nginx在日志中要求你增加worker的提示。

php-fpm：

pm = dynamic/static; dynamic时有最大进程最小进程之说，static时没有。只有一个上限。
pm.max_children = 50;强制的一个阀门，后面的设置里，进程数不能大于这个。
pm.start_servers = 20;启动时启动的fastcgi进程。
pm.min_spare_servers = 5;最小fastcgi进程数量，dynamic有效
pm.max_spare_servers = 35;最大fastcgi进程数量，dynamic有效

php没有异步进程概念，如果要使用php作为接入层，需要自己完成NIO扩大接入能力（接触到的ICE、thrift在php中都是同步操作）。而接入能力就取决于上面的配置。

java:
java优秀的NIO框架netty。
servlet3.0实现了异步请求的context，目前还没有在平常框架中进行使用。一般的用法为comet push server，性能未知。
一般来说，用java做接入层很容易变成了业务层。（但是，为什么不呢？）

tomcat 7.0.x提供了servlet3.0的这一特性，CometProcessor interface。
resin 4.x提供了servlet3.0的这一特性，GenericCometServlet。

从名字看，大家都一致性地认为这一特性适合用来做comet server。（理论上可接入无限用户，直到费尽cpu、内存，服务器死机、jvm oom）

经过上周一周朋友们帮忙测试和bug fix，nginx_http_hashdos_module已经达到可以线上使用的水平，下面是使用记录。
下载

#wget --no-check-certificate https://github.com/54chen/nginx-http-hashdos-module/zipball/master
#mv master nginx_hashdos.zip
#unzip nginx_hashdos.zip

编译安装

#tar zxvf nginx-1.0.xx.tar.gz
#cd nginx-1.0.xx/
#./configure --prefix=/opt/soft/nginx --with-pcre --user=www --group=www --with-http_stub_status_module --with-http_ssl_module --add-module=../54chen-nginx-http-hashdos-module-f84d909
#make && make install

配置注意事项
在http段，增加如下：

hashdos on;
body_max_count 1000;

在各自的location段，要按照业务情况来加：

client_body_buffer_size 2m;
client_max_body_size 2m;

*上述两个值一定要相等。

如果是普通的discuz，上传上限是1m的，可以修改为1m。
如果是没有上传功能的普通网站，建议修改为512k。

起因：
Wed, 28 Dec 2011 22:28:16 GMT apache tomcat公布了一个安全漏洞。

http://mail-archives.apache.org/mod_mbox/www-announce/201112.mbox/%3C4EFB9800.5010106@apache.org%3E

漏洞原理：
依靠相应语言的hashtable/hashmap实现过程（request多为此结构），当不同的key存入时如果hash值相等则以链表方式连接在前面。此漏洞利用碰撞相同的hash值得到一个长链表，重新get时，map的计算过程会将时间复杂度巨增，原来一个简单的过程将变成一个很费cpu的过程。

影响到的：
最快时间tomcat公布了解决办法。
php进行了升级。
ms也发了公告http://technet.microsoft.com/en-us/security/bulletin/ms11-100。

解决办法：
tomcat
临时办法：
默认大小2097152，当maxPostSize=0时，不限制；maxPostSize=20971520时，为20M，改为一个小于10k的值，所有版本可用，会影响用户。
持久办法：
用新的版本，maxParameterCount默认值1000。
nginx
临时办法：
默认的最大请求body大小为8m，修改设置client_max_body_size=10k；此招为各种情况下万金油，会影响用户。
持久办法：
暂无，应该很快会有max_request_count的参数。
php
持久办法：
php升级到5.3.9，5.2需要打patch。详细见：http://www.laruence.com/2011/12/30/2440.html

后记
54chen人肉构造打到php，php立马100%，转到java（resin+spring+rose），轻松化解，没有反应。

准备三台机器：
r1
r2
r3

准备erlang环境：
Erlang >= R14B03
yum install gcc glibc-devel make ncurses-devel openssl-devel
$ wget http://erlang.org/download/otp_src_R14B03.tar.gz
$ tar zxvf otp_src_R14B03.tar.gz
$ cd otp_src_R14B03
$ ./configure && make && sudo make install

git环境(看上去是非必须的)：
yum -y install git

下载地址：

http://downloads.basho.com.s3-website-us-east-1.amazonaws.com/riak/CURRENT/riak-1.0.2.tar.gz

cd riak-1.0.2
make rel

修改配置文件后启动
riak start
riak-admin join
过程完全同0.142
http://www.54chen.com/_linux_/riak-source-install-run.html
与0.1.42相比：
erlang环境要求R14B03及以上。低版本会出现this emulator supports only up to 149的make错误。

使用leveldb为存储引擎：
默认引擎还是bitcask，需要修改配置文件app.config
{storage_backend, riak_kv_bitcask_backend}
改为：
{storage_backend, riak_kv_eleveldb_backend}

官方说明：
bitcask适用于key有限，而需要最大量的吞吐量和数据持久化情况。
leveldb适用于大量的key。

官方java client压力测试结果：
1cpu 8G的机器3个 笔记本运行压力程序 读写比3:1 6并发 1k大小的value
PB：2500ops 99.9%的操作在22ms内。
HTTP: 1000ops 99.9%的操作在30ms内。

过去一年时间里，都在做中国移动互联网下的API设计工作，所面对的情况可能是最具中国特色的了。如果你在尝试构架一整套的新的API供你的客户端使用，可以尝试以下的几点：
1）api所使用协议，要能够不怕被加js、加广告和各种代码。
全国各地的运营商，有习惯挂广告、加代码等等，要做的事情就是在客户端做各种解析判断。实践证明，这帮孙子的设备是检测http协议的head头里的content-type，如果是html/text则会加，如果是text/json就不加了，所以，你懂的。

2）api可视化
你的app上架了，后端也布好了。然后呢，就天天看下载量。但后端好坏一问三不知。所以在设计api时，要提前回答以下问题：
1.此时此刻，有多少个app正在调用这些api，每分钟多少个？
2.他们（api）有快？
3.能否很简单地通过浏览器快速debug？
4.能否快速禁止单个用户？

3）链路
在幅员辽阔的我国，总是一个地方到一个地方的IDC直接就ping不通（移动互联网下更甚）。于是需要花钱自己打通这些地方，没有专线，只有代理再代理。

4）api quota与perfcounter
对api进行quota限制，针对每个api每个人，都有限额。
这个限制的传统做法：
1.每天的上限调用次数。每天半夜清空，一天一个量累计。
2.每分钟的频度。这个防止有恶性的突发情况。
上述二者，缺一不可。
perfcounter用于对api的监控设计指标，如果一个api有异常，应当十分灵敏地得出结论，而不是误报连连。

系统监控工具monit是一款功能非常丰富的进程、文件、目录和设备的监测软件，用于Unix平台。它可以自动修复那些已经停止运作的程序，特使适合处理那些由于多种原因导致的软件错误。

安装
centos:

yum install monit

ubuntu:

apt-get install monit

使用
配置文件在/etc/monit.conf

配置发邮件的smtp服务器

set mailserver 111.111.111.111 USERNAME "xxx@xiaomi.com" PASSWORD "54chen54chen"

配置服务检测的周期

set daemon 30
30秒检查一次

配置报警邮件格式

set mail-format {
from: ALERT
subject: $SERVICE $EVENT at $DATE
message: Monit $ACTION $SERVICE at $DATE on $HOST: $DESCRIPTION.
}

配置收报警的人

set alert 54chen@xiaomi.com with reminder on 3 cycles ；出问题时最多连续报3次

配置监控对象

check host webim-91 with address 192.168.1.2
if failed host www.miliao.com port 80 proto http and request "/test.html" for 2 times within 2 cycles then alert

其他
可以监控的类型有： CHECK PROCESS FILE FIFO DEVICE DIRECTORY HOST SYSTEM

帮助

man monit