tongweb集群部署
去年冬天，群部一个客户的群部生产环境出了怪事：两台 TongWeb 节点，一台 CPU 飙到 90%，群部另一台闲得发慌。群部查了半天，群部发现是群部会话粘滞没配好，所有用户全被怼到同一台机器上。群部这事让我意识到，群部TongWeb 集群部署不是群部把几台服务器启动起来就完事，细节没抠对，群部集群反而比单机更脆弱。群部
先说部署前必须确认的群部东西。TongWeb 的群部集群依赖一个共享的“注册中心”来协调节点状态，通常是群部内置的 multicast 或者指定一台节点做 master。我习惯用单播方式，群部因为很多云环境直接禁掉了 multicast，你配了也白配。具体在 tongweb.xml 里找到 <cluster> 段，把 multicast 改成 false，然后手动列出所有节点的 IP 和端口。这一步漏掉，节点之间根本看不见对方，日志里会一直刷“找不到集群成员”。
节点配置有个容易踩的坑：server.name 必须唯一。有人图省事，复制粘贴配置文件，忘了改这个名字。结果启动第二个节点时，第一个节点直接掉线——TongWeb 认为同一个名字的节点重复加入了。我见过最离谱的一次，运维把两台机器的 server.name 都设成 node1，折腾了一下午才发现。
会话共享是集群的核心。TongWeb 支持两种方式：内存复制和持久化到数据库/Redis。内存复制适合小规模（3 节点以内），配置简单，在 tongweb.xml 里打开 <session-replication> 就行。但节点超过 3 个，广播风暴能把网络打满。我一般直接上 Redis 方案，把 session-manager 的 type 改成 redis，填好连接信息。注意 Redis 的 key 过期时间要设得比 session 超时略长，否则会出现用户还在操作、session 已经没了的诡异现象。
负载均衡器这块，Nginx 或者 F5 都行。关键就两点：健康检查路径别用默认的 /，TongWeb 默认页可能返回 200 但应用已经挂了。我通常让应用暴露一个 /health 接口，检查数据库连接和关键线程池状态。第二点是粘滞会话，如果你用了 Redis 共享 session，粘滞可以关掉；如果用的内存复制，必须开粘滞，否则用户请求在两台机器间跳来跳去，session 对不上。
有个细节很少人提：TongWeb 的集群节点时间必须同步。差超过 30 秒，session 的 lastAccessTime 就会乱，导致 session 提前失效或者永不过期。我吃过这个亏，一台机器快了两分钟，用户登录后每隔几分钟就被踢一次。后来在所有节点加了 NTP 校时，问题消失。
部署完别急着上生产。先做一轮“拔线测试”：手动停掉一个节点，看负载均衡器多久能摘除它，剩余节点能否正常接管。再模拟 Redis 宕机，观察 TongWeb 是降级到本地 session 还是直接报错。这些边界情况，文档里不会写，但生产环境一定会遇到。
最后说个主观判断：TongWeb 集群的稳定性，七分靠配置，三分靠运维。配置错了，集群就是灾难放大器；配置对了，它比单机可靠得多。别迷信“一键集群”脚本，那些东西隐藏了太多关键参数，出问题时你连日志都看不懂。