楼主描述太长了，可能理解不太精确。

3个方案：
1. 能否在跳板机上映射一个端口，或者为每个远程服务器分别映射一批端口
比如 10022 -> server1:22
10122 -> server2:22
本地只要连跳板机的 10022端口就相当于连到了server1的22端口

2. 本地用ssh直接映射端口到本地
ssh -fN -L 10022:<server1>:<server1_port> -p <跳板port> <跳板user>@<跳板ip>
ssh -fN -L 10122:<server2>:<server2_port> -p <跳板port> <跳板user>@<跳板ip>

然后 ssh -p 10022 <server1_user>@localhost 就能连到server1
ssh -p 10122 <server2_user>@localhost 就能连到server2

3. 跳板机上架设socks5 proxy服务器（即使有密码也不太安全）
ssh -o "ProxyCommand nc -x <跳板ip>:1080 %h %p" <server1_user>@<server1_ip>

看多大量以及后续怎么用

我这边是直接扔leveldb中

都走ssh了，rsync://path/to/project/doc 这里应该直接 user@host:/path-to-doc 吧

@dorentus 绝对是dnspod免费版的问题。dns网络问题的话会自动重试其他服务器的，目前造成这个错误的原因就是因为偶尔dnspod返回的结果有误导致的。去年底和几个月前分别确认过2个bug并告知他们，并回复已经修复。但是不排除还有其他类似bug

dnspod的话还是推荐它的付费版（尤其访问量大的网站），还没遇到过问题。

dnspod付费版在用，稳定
dnspod免费版也在用，帮他们找过2次bug，其实不是挂，就是偶尔返回记录是错误的（一个死循环结果），导致各地dns cache的记录也是错误的，于是某ttl时期内就“挂了”。（这2个bug对简单的A记录没什么影响，可能大多数人不会影响到）

这种基础服务，一个月2次dns解析错误就已经很“经常”了

看数据的话 hk.v2ex.com 更慢，因为waiting 时间更长

估计hk那个是proxy,hk到实际服务器可能并不快

ping www.v2ex.com 190ms
ping hk.v2ex.com 50ms

但是浏览体验上几乎没有差别

原来组织在这里

我们公司所有服务器都是freebsd

@soli 不是严格意义上的热备
我这边应用比较特殊，数据都是只读即可

本地有专门生成数据的机器，把数据存入本地leveldb，同时程序会把写入的数据加入一个同步队列，然后另外一个同步程序定时把队列里的数据同步到几台服务器上并写入服务器上的leveldb。

@lookhi
@Chewbacca
@soli
@clowwindy
@LazyZhu
感谢，数据已经修复。 leveldb没坑我，是自己把自己坑了 :(

数据都是snappy压缩的，那个redis-storage我为了部署方便是直接把leveldb和snappy静态编译好然后从其他机器copy过来的。


而当时为了修复数据，直接在数据库所在机器安装了leveldb。但是坑爹的是没有连接上snappy库，我记得确实选择了SNPPY的。
后来发现在freebsd ports里面反复安装leveldb，虽然有SNAPPY选项，但是确实没法链snappy进来，于是手动修改了一些编译配置，终于把snappy编译进来了。



重新用那段python脚本，修复后基本上数据都在。

几年前国内有过，饭统网搜索就用他家的，忘了叫啥了，不知道现在还在不在 -_-

不太了解tornado,
是否可以这样架构：
1、Tornado只负责和websocket以及用户交互服务
2、写个聊天业务进程，跟那些tornado进程网络通信，并负责聊天业务处理，只要知道用户在哪个tornado 上，就命令哪个去处理。把这个当成中枢，把那些tornado当成跑腿的

leveldbutil dump *.sst
全是
Corruption: corrupted compressed block contents

看来是没戏了

vr现在正常了，周六的时候也有过一次

@LazyZhu thanks ，新项目可以尝试

15:47 vr正在抽风中..... 丢包50%

@clowwindy 那机器上跑了十几个leveldb库，就这个出问题了，看来还是存在一定的损坏概率。

另外就是数据恢复工具缺乏，那RepairDB()也太简陋了