为什么会有Memlink?

对于大型论坛服务，比如百度贴吧、天涯论坛，日均发帖量过百万或千万，日均PV过亿，日积月累下来的帖子数量可能几十亿到上百亿。这种超级论坛，其海量存储、海量访问都是一个非常有挑战性的技术难题。

中 小规模的论坛（Phpwind/discuz）通常使用mysql/sql server作为后端存储，当数据量膨胀时，比如一个版面有百万、千万级别主贴，一个主贴下有数百万回复，此时使用SQL语句select … order by … limit … 进行数据查询和展现，性能可想而知。

大型论坛中的数据可以抽象为如下三类数据模型：

1. Key=>Value结构数据。比如：版面信息、主帖信息、回帖信息等。主贴id对应主贴的信息（标题、发帖时间、作者等等），回帖id对应回贴的信息（回复内容、回复时间、回复者等等）。
2. Key=>List结构数据。比如：主贴列表，主贴列表按发表时间或者最后回复时间进行排序；回复列表等等。
   Key=>List通常有如下特点：
1. 可排序
2. 可动态调整顺序
3. 其他周边数据（SQL系统/检索系统）。比如：斑竹、会员、友情版面/链接等等，由于数据量较小、逻辑关系较复杂，可以使用sql系统存储；比如帖子检索可以使用检索系统。

对于Key=>Value系统，市面上有较多选择，它们的数据容量大小从数百万到上百亿不等，性能、功能也各有差异，由于讨论KV系统的文章很多，再次不赘述。

对于Key=>List系统，市面上可选择的余地非常小，加之线上工业级别的一些要求，经对比了一些Key=>List系统（Redis），最终选择开发memlink系统，同时开源出来，也希望为业界同行提供多一种选择，繁荣开源社区。

Memlink简介

Memlink 是一个高性能、持久化、分布式的Key=>List/Queue数据引擎。正如名称中的Memlink所示，所有数据都建构在内存中，保证了系统的 高性能(读性能大约是Redis几倍到十倍)，精简内存（内存消耗大约是Redis的1/4），使用了redo-log技术保证数据的持久化。此 外，Memlink还支持主从复制、读写分离、数据项过滤操作等功能。

特点：

• 内存数据引擎，性能极为高效
• List中的Node采用块链组织，精简内存，优化查找效率
• Node数据项可定义Mask表，支持多种过滤操作
• 支持redo-log，数据持久化，非Cache模式
• 分布式，主从同步
• 读写分离，写优先处理。

与Redis区别

Redis同样也提供key=>list 存储功能，Memlink与Redis区别有：

• Redis比较消耗内存。每个存储节点，在不支持vm的情况下要额外消耗12字节内存，在支持vm的情况下，每个节点额外消耗24字节内存。对于存储上亿条数据来说，额外消耗的内存太大。
• Redis redo-log不够完善。redis提供了两种redo-log机制，机制一：每隔一段时间同步磁盘（此期间重启会丢失部分数据）；机制二：追加log方式，会使log文件越来越膨胀，造成性能不优化（需采用额外命令减小log）。
• 主从同步不完善。如果slaver因为某原因丢失了部分同步数据，需要重新完全获取一份主节点的所有数据。在大数据量的情况下，不太合适线上生产的需求。
• 网络处理主事件循环只有一个线程，不能很好的利用多核；同时读写没有分离，没有进行写优先处理。
• List中的Node没有mask表，不能进行一些属性过滤。

Memlink主要对上述特点进行了改进。

性能测试

硬件

• CentOS release 4.6 (Final)
• Kernel 2.6.9-67.0.22.ELsmp 32位
• Memory 4G
• CPU Intel(R) Xeon(R) CPU E5405 @ 2.00GHz （四核）
• Disk 250G SATA
  

客户端

• 10个客户端，并发短连接
• Memlink内部开启4个处理线程。
• Redis只支持单线程模型。结果表格中的hiredis为使用hiredis客户端测试的结果。redis为官方的redis-benchmark测试结果。

		1w	10w	100w	1000w
insert	memlink	9665	9650	10078	10183
	hiredis	9381	9489	8993	8976
	redis	9285	9290	9287	8835
	mysql	5623	5621	5468	5306
range first100	memlink	17400	17504	16614	17292
	hiredis	1695	1637	1696	1586
	redis	4629	4587	4504	4545
	mysql	2210	2286	1955	1611
range first200	memlink	15786	15772	15964	16180
	hiredis	711	711	719	692
	redis	2941	2949	2941	2857
	mysql	1444	1791	1870	1402
range first1000	memlink	3795	3918	3703	3250
	hiredis	118	115	116	114
	redis	761	739	761	735
	mysql	550	692	620	686
range last100	memlink	16989	16502	13118	319
	hiredis	2132	240	20	2
	redis	4385	191	19	2
	mysql	80	8	1	-
range last200	memlink	15915	15596	12203	316
	hiredis	743	229	20	2
	redis	2941	182	19	2
	mysql	94	9	1	-
range last1000	memlink	3893	3641	3332	299
	hiredis	120	174	19	2
	redis	756	149	18	2
	mysql	94	9	1	-

详细性能测试请见Benchmark

Client API

客户端命令描述：

详细客户端API请见ClientAPI

谁在使用?

目前Memlink应用于天涯来吧、天涯论坛系统。 未来Memlink的Key=>Queue会应用在天涯微博系统上。

未来

Memlink 是专注于Key => List/Queue对象的存储系统，它内存使用更精简、性能更高效。 Key => List/Queue系统作为Key => Value另一种形式补充，为高性能、海量数据的Web应用提供了新的数据存储模型选择。

以下是对天涯社区在北京研发中心的技术负责人冯勇先生的实录采访：

1. 您好，能请您先自我介绍一下吗？您最近在做哪些有趣的事情呢？

    大家好！我是天涯技术中心系统平台部负责人冯勇，系统平台部是今年刚组建的部门，旨在优化天涯线上产品的系统架构。天涯是一个有十二年历史的网站，对于一个累积了十二年补丁的系统进行重构、优化，本身就是一件很有趣、很有挑战的事情。

2. 是出于什么初衷，天涯会开发出这样一款数据引擎出来呢？并且最后要开源出来。