作者:AngryFox 分类: Uncategorized July 23rd, 2014 暂无评论

VM SYNC->PV前端FLUSH->后端->host->cache系统->分布式存储系统
buffer write平均在212MB/s,direct write平均在68MB/s,而direct+sync则平均在257kB/s
几种写IO的模式:

buffer write,写入目标是guest OS的page cache,通过writeback刷到硬盘的缓存,然后再通过自动刷或者sync命令触发的方式刷到持久化存储介质上。这种写方案的速度很快,缺点是数据完整性无法得到严密保证(取决于回写的策略),而且回写有可能引起阻塞而影响服务质量
direct write,从应用直接写到硬件上的缓存,绕过操作系统的page cache。比如MySQL引擎自己有缓存机制,就可以使用direct write写到硬盘缓存然后再通过sync命令刷到下面的存储介质。绕过page cache的好处是避开了回写的影响,但数据仍然不是绝对可靠,sync完毕之前数据仍然是不安全的
write+sync,写入page cache的同时即调用sync/fsync直接写到存储介质,sync返回算成功。此方式的好处是数据足够安全,缺点是慢,具体等待时间随着操作系统内存使用情况的不同而不同
O_SYNC,加了此标签的写入操作会在数据写入硬盘缓存时同步刷到碟片上

HDFS
S3
Nagios
Bilty使用的实时分布式消息系统是Nsq。
Bitly使用hostpool管理一系列的主机。

组件并发:A机器和B机器同时工作,这就是如何获取横向扩展能力。很强大但是成本是需要在不同机器间协调。例如,当锁数据使机器互相等待彼此,这就不能算是并发了。
缺少全局clock:每个机器有一个不完美的clock,当有超过一台机器并且每台机器有它自己的时间定义,这就意味着发生在不同机器上的事件不能基于时间排序,对bilty而言如果事件相差1到2秒,它们就不清楚哪个先发生了。
故障独立发生:如果A发生故障了,B应该继续工作。

更好的系统间隔离。一个命令意味着必须知道谁收到了该命令,否则它没有任何意义。说某个事件发生则意味着我们并不需要关心谁消费了该消息。只需要通知X发生了,其他服务则可以做对应的增量更新,或者相应的操作。
事件通常映射为多个消费者处理的消息。当一个Bitly URL被解码为HTTP重定向,消息会发送给多个服务:一个持久化服务奖它保存到HDFS及S3;一个实时的分析服务;更长一点的离线历史分析服务;一个注解服务。解码服务只需要把这个时间发布,而不需要去了解任何下游服务。而下游服务关心的只是捕获这个服务,而不管谁给它发送。
非常容易地添加新的消费者。可以建立一个新的服务,与某个事件关联,生产者并不知道也不关心。一个服务如何处理事件的变化同样的不关心生产者。生产者和消费者是分离的,只通过指定的事件状态关联。

show engine innodb status\G和show full processlist