Cluster 未必一定要用 session replication。

简单给你列几个解决方案：

1. Session sticky: 通过在 LB 上设置。 优点：开销最小，实现简单。缺点：其中一个 node down 了，session 将会直接丢失。

2. Session replication: 在不同 node 上进行 session 同步。 优点：效率比较高。缺点：当架构中 node 比较多的时候，session replication 所带了的 traffic 将会是你的噩梦，而且不易于扩展 node，因为 session replication 需要节点中的 node aware 所有的其他 node 节点，增加一台 node 需要更新其他所有 node 配置。

3. Session centralization: 将 session 存储到一个 server 上，所有的 node 都连接到这个 server 存取 session。 优点：node 易于管理，扩展。缺点：一般 session server 也需要做一个小的 cluster.

不知道你们在说什么

#2 楼 @huacnlee 问题是：集群的时候如何保持用户状态同步。ruby-china 好像没有做集群，我每次 ping 到的 IP 相同。如果是集群，我登录了 ruby-china，后台有了 session 数据，nginx 做负载均衡 (只考虑七层负载情况) 的时候会根据策略走不同 node，那么如果开始的 session 没有做同步处理，我访问不同节点时登录就失效了。 @boyishwei 第一种没见过，二在 tomcat 见得比较多，三是我觉得比较适合 rails 的，用 redis 来保存，cluster 也还方便。

#3 楼 @flowerwrong 谁说不同步的

Ruby China 的 Session 是放 Cookie 的（就算放服务端也是没问题的，Memcached, Redis, 其他任意速度快的内存数据库都能解决问题）

一般默认都是放 cookie，如果考虑全面一点就放内存数据库，cookie 里存放 session 的 key 就 OK 了。

1 你的负载均衡软件要做到访问者在相当长时间内只能被分到一台 server 上 不要跳来跳去 2 尽量不要用 server 端存储，如果用到，要放到单独的存储中去，这样个 server 都能拿到，比如 asp.net 的 session 可以存到 数据库里。

仅仅是登陆问题，cookie 就基本够了。

rails 的 session 默认存储方式就是 cookie，所以不存在 sesson 不同步的问题

@flowerwrong Session Sticky 就是让同一个 user 的 request 始终 talk 到同一个 back end server，一般在 LB 上设置，比如 HAProxy, Nginx 或者是 AWS 的 ELB 都支持 Session Sticky.

另外我还少列了一种，

1. Store Session in Cookie, Rails 就是这样做的，这样也可以实现一个 non-sharing 的 deploy architecture，但是缺点是 session 数据是存储到客户端 cookie 中，容易被劫持，cookie 也存在大小限制（一般也够用），而且只能存放基础类型的数据，比如字符串什么的（如果我想在一个 session 中存放某个对象就不行）。

根据你项目的规模跟需求，选择不同的架构方式。比如规模，用户群都还不是很大，直接使用 Session Sticky，简单易用，不需额外的代码更改即可支持。复杂点，系统高性能，高安全性，高可扩展性，绝对不能 down 机，就用 Session Centralization。

#8 楼 @boyishwei :plus1: 还有一个问题，怎么处理多地甚至多国服务器呢？ 我的想法：

1. 一个总代理，根据 IP 判断地区和国籍，再走下一层分代理
2. DNS 层做负载均衡，具体未知

#9 楼 @flowerwrong DNS 智能解析啊，费那么大事干嘛