都是 Latency 惹的祸 & 谈 CSDN TUP

版权声明: 允许非商业性转载，但转载时必须标明原作者 fcicq、原始链接 http://www.fcicq.net/wp/?p=924 及本声明。

首先是五分钟法则的问题.
The Five-Minute Rule 20 Years Later: and How Flash Memory Changes the Rules

文章本身是很有意思的, 两年又过去了, 可以算一算现在的机械硬盘与 SSD 的价钱.

BreakEvenIntervalinSeconds = (PagesPerMBofRAM / AccessesPerSecondPerDisk) × (Price-PerDiskDrive / PricePerMBofRAM).
(另一个相对的公式不列了)

慢. 这个公式有个问题. 当然对缓存来说这基本是对的.
如果查询 item 存储位置的算法复杂度不是 O(1), 这个公式就要重新考虑了.

当然, 准确来说, O(logn), 这个 n 在一段时间内不会发生数量级的变化. 可以认为是常数.
但它既然不是 O(1), 那就应该把它算出来.
这里特别拿 B-Tree 来说, 要看这个树有几层. 有多少层已经被缓存到内存里了.
长期使用有 split 的问题. 空间利用率也不会到 100%.

此外 B-Tree 还有 Page Size 的问题. 原文说的很详细. 不提.

需要注意的一点是, B-Tree 的(随机)插入复杂度不可忽略.
B-Tree 不适于高 IOPS 的场合, 即便是 SSD.

—

CSDN TUP 的问题.

实时搜索.
P6 的中间, 加上 P8-9 的描述, 就是个 BigTable 的简化版.
如果有必要的话可以谈一谈 Bigtable 和 Cassandra.

内存 snapshot db 如果是可用性考虑的话好像有点道理,
这就相当于 memtable 大小设成内存一半略少.
如何平衡 bigtable 的几个 tuning 参数也是个小问题.

Feed 系统.
序列化, 压缩: Protobuf, QuickLZ
模板用 CTemplate 并不奇怪. memcached, tokyo tyrant 比较常见.
值得注意的是 Boost multi-index container 和 Flyweight.

以下摘自 http://flustar.javaeye.com/blog/160829

一、FlyWeight模式定义:
运用共享技术有效地支持大量细粒度对象。
二、模式解说
也就是说在一个系统中如果有多个相同的对象，那么只共享一份就可以了，不必每个都去实例化一个对象。在Flyweight模式中，由于要产生各种各样的对象，所以在Flyweight(享元)模式中常出现Factory模式。Flyweight的内部状态是用来共享的,Flyweight factory负责维护一个对象存储池（Flyweight Pool）来存放内部状态的对象。Flyweight模式是一个提高程序效率和性能的模式,会大大加快程序的运行速度。

对于 multi-index container 没有什么可评论的. 内存里怎么搞都行.

需要解决的问题方面, 数万每秒写入, 几千随机读都不是什么大问题. 不用 B-Tree 是第一步?

Direct IO 有人喜欢有人烦. 偶属于不喜欢也不排斥 Direct IO 的那种.
个人认为只有碰到 Double Caching 的情况再用.

关于用 Tokyo Tyrant 存 user-server 的做法, 越看越像 riak’s bitcask.

留一个算法复杂度分析当作业好了, 当然这里要考虑磁盘输出和 IOPS 的问题. 上面都说了一半了.

微博架构.

首先是 Push / Pull 的问题.
偶考虑到的是,
1 在线用户数量?
2 是否应该为非注册用户提供这么多实时服务?
3 用户分组带来了哪些影响?
4 服务利用率? 能否利用运营/用户监控数据? —那些不活跃的用户就不用…

要是偶会做两步.
1 hover 到推送 item 上的时候返回一个 beacon 回服务器. 分析这些结果.
2 偶要从应用上做监控, 看究竟有多少人真正得到了推送数据. 这个利用率如何. 比较哪种方式开销小.

关于 memcached 分组/库的问题没什么意见.
但 memcached 内存利用率低是众所周知的? 浪费一点也是浪费, 对吧.
这里有一个平衡问题(要容量还是要吞吐量). 还要注意前面提到的五分钟法则. 这是对普通场景来说的.
但这种 Cache 使用方式决定, 法则不适用于这种场景.
新浪这种发展模式本身注定就是自找事, 偶说把僵尸用户处理一下(加个 flag 不考虑对它们的推送), 问题说不准就可以再推迟上半年.

以下摘自 关于新浪离职

这中间有个问题是，确定需求的人基本不关心技术架构，都是在需求确定之后，讨论实现方案。

hotkey & mutex. 加一层 proxy 是可以了.
用 gearman + uniq 的方法看起来像 RPC. 那这个事情就应当作为 RPC 来看.
直说来还是技术上有问题. 对同一个请求你敢让多少台机器帮着处理? 数据的缺漏对这个应用来说并不关键.

回到 memcached 的话题. 如果都这么穿透到 db 的话, 是不是对 db 的保护不够呢?
还要加 db proxy layer 吗? 还是干脆只允许专门的机器处理数据库访问?

ps:
更尖锐一点说, 为什么数据库那么脆弱 ?

ps2:
“明白运作原理是部署应用的前提” 这句话对吗?

友情提示: 请注意文章的时效性与准确性, 作者不对文章的有效性负责.