w***g
发帖数: 5958 | 1 我觉得这东西不用上数据库。如果想实时恢复的话是这么搞的：你每做一步操作都先把
这个操作写入磁盘，等确认写进去了再返回用户请求。系统崩溃后把磁盘上的journal
读出来replay。你一开始上journal后肯定慢的要死。然后我们再看怎么优化这个系统
。普通磁盘写入速度也能达到100MB/s，差不多和千兆以太网差不多，高峰的时候稍微
牺牲点延时把log汇总后写入。应该能够做到和网速相匹配。而且磁盘吞吐量不够多弄
几块磁盘就可以了。 |
g*****g
发帖数: 34805 | 2 没有你这么算的，一次写1K, 写1K次，跟一次写1M能一样吗？
你要确保不丢，就得fsync。
journal
【在 w***g 的大作中提到】
: 我觉得这东西不用上数据库。如果想实时恢复的话是这么搞的：你每做一步操作都先把
: 这个操作写入磁盘，等确认写进去了再返回用户请求。系统崩溃后把磁盘上的journal
: 读出来replay。你一开始上journal后肯定慢的要死。然后我们再看怎么优化这个系统
: 。普通磁盘写入速度也能达到100MB/s，差不多和千兆以太网差不多，高峰的时候稍微
: 牺牲点延时把log汇总后写入。应该能够做到和网速相匹配。而且磁盘吞吐量不够多弄
: 几块磁盘就可以了。
|
w***g
发帖数: 5958 | 3 高峰的时候用户很多啊，我稍微pool一下就攒起来了。刚刚还说TCP_NODELAY，咱也得
举一反三以下吧。再说我一台机器上挂4个硬盘，要跟网卡匹配只需要达到25Mb/s。
我说的是在自己家里玩的配置。生产系统的话就用Fusion IO了。
【在 g*****g 的大作中提到】
: 没有你这么算的，一次写1K, 写1K次，跟一次写1M能一样吗？
: 你要确保不丢，就得fsync。
:
: journal
|
g*****g
发帖数: 34805 | 4 pool你崩的时候，丢的单子就多了。
【在 w***g 的大作中提到】
: 高峰的时候用户很多啊，我稍微pool一下就攒起来了。刚刚还说TCP_NODELAY，咱也得
: 举一反三以下吧。再说我一台机器上挂4个硬盘，要跟网卡匹配只需要达到25Mb/s。
: 我说的是在自己家里玩的配置。生产系统的话就用Fusion IO了。
|
w***g
发帖数: 5958 | 5 反正大家都是不断地刷屏，断了也会不断刷的。只要一两分钟能恢复过来应该没问题。
【在 g*****g 的大作中提到】
: pool你崩的时候，丢的单子就多了。
|
g*****g
发帖数: 34805 | 6 不大量丢单，也是前提之一。前提不一样，难度差别太大了。
【在 w***g 的大作中提到】
: 反正大家都是不断地刷屏，断了也会不断刷的。只要一两分钟能恢复过来应该没问题。
|
n*****t
发帖数: 22014 | 7 LOG 在前置机做，收到座位 ID 记录一下，如果中心节点崩了，拿几个前置机的 LOG
就能生成当前余票了。
journal
【在 w***g 的大作中提到】
: 我觉得这东西不用上数据库。如果想实时恢复的话是这么搞的：你每做一步操作都先把
: 这个操作写入磁盘，等确认写进去了再返回用户请求。系统崩溃后把磁盘上的journal
: 读出来replay。你一开始上journal后肯定慢的要死。然后我们再看怎么优化这个系统
: 。普通磁盘写入速度也能达到100MB/s，差不多和千兆以太网差不多，高峰的时候稍微
: 牺牲点延时把log汇总后写入。应该能够做到和网速相匹配。而且磁盘吞吐量不够多弄
: 几块磁盘就可以了。
|
