idea's blog

我写了一个简单的循环程序往 LevelDB 写数据进行测试, 发现偶尔会出现停顿的情况, 单个写操作可能会耗时超过1秒. 这种慢请求是非常致命的, 因为在高并发的 Web 应用中, 1秒钟影响到的用户是成百上千个.

经过分析, 发现 LevelDB 实现了写限速机制, 当 Level-0 的 sst 文件数超过一定数量时开始限速, 再超过一定数量时, 直接主动的阻塞写操作, 直到 Compaction 线程减少了 Level-0 的 sst 文件数量减少到阀值以下.

Continue reading »

经过半个用的开发和测试, SSDB 发布了新版本 1.4.0. 这个版本最大的改进是重新设计了主从同步机制, 数据同步更安全, 另外还支持双主(多主)同步模式. 目前, 单主模式的主从同步功能是稳定的, 而双主(多主)模式从 experiment 升级到 beta 阶段.

此次的更新包括:

• 主从同步机制重新设计, 双主(多主)模式进入 beta 阶段
• info 命令返回更多的统计信息, 包括每个命令的请求次数和消耗时间和等待时间
• 升级为 LevelDB 1.9.0

此次升级还探索了多线程处理模型, 将写操作或者读操作分配到独立的线程池中进行处理. 但经过测试, 性能下降了20%左右, 所以多线程处理模型没有被采用. 多线程处理模型的主要延时发生在 IO 线程将请求分配给工作线程的过程, 为了对处理线程的结果进行 select, 所以采用 pipe 进行消息传递. 但 pipe 延时在 10 us(微秒)左右, 这个成本非常大.

SSDB 双主(多主)模式的使用文档: https://github.com/ideawu/ssdb/wiki/Replication#master-masterbeta

SSDB 目前已经进展到 1.3.x 版本, 在使用过程中, 程序一直非常稳定, 内存占用也很合理, 即使在一个40G数据在应用中, 内存占用也稳定在1G左右.

最近, SSDB 被应用到了一个极端的环境, 这是一个图片相关的应用, 给 SSDB 造成的压力就是:

1. 单条数据较大. 一般的应用也就几K级别的单条数据, 但图片处理一般在1M级别
2. 并发数较多, 达20K+

Continue reading »

Google 公司开源的 LevelDB KV 存储引擎是一个非常不错的东西, 支持 zset 数据结构的 SSDB 存储服务器便是使用 LevelDB 作为存储引擎. SSDB 的目的是用来替代 Redis, 作为大数据量存储的服务器. 为什么要在 LevelDB 上面做封装呢? 因为传统的 KV 存储天生不适合存储集合数据, 但实际业务几乎都要求处理集合数据.

LevelDB 将数据写到磁盘上以保证持久化, 但一个重要的问题是, LevelDB 会丢数据吗? 如果程序意外退出, 或者机器掉电, LevelDB 的数据会丢失吗? 其实, 包括 Redis 在内, 甚至是所有的关系数据库系统, 也会面临这个问题.

LevelDB 的写操作是直接操作文件描述符的, 虽然不是带缓冲的标准 IO 的 FILE, 看起来数据会被立即写到磁盘上, 但这个"立即"所对应的时间可就长了.

首先, write() 函数返回时, 数据可能并未到达磁盘, 甚至到达了磁盘也可能只存在于磁盘的可丢失缓冲区. 当然, 如果数据确实达到了磁盘, 丢失的机率就非常小了. 数据何时被写到磁盘, 一般由操作系统内核控制. Linux 内核默认需要 30 秒才将数据刷新到磁盘上. 30 秒可是很长的时间! 丢失的数据可能达到几十万条.

而 LevelDB 使用了 mmap, 这个时间可能更长!

我给 LevelDB 提了一个 issue, 希望能给加上一个类似 Redis 的 sync everysecond 机制, 起一个单独的线程, 每隔一秒将数据刷到磁盘. 不过, 开发者认为这个线程不应该被加入到 LevelDB 里, 而是应该由使用者自己来实现.

一些有用的讨论: http://oldblog.antirez.com/post/redis-persistence-demystified.html

SSDB是一个开源的高性能数据库服务器, 使用Google LevelDB作为存储引擎, 支持T级别的数据, 同时支持类似Redis中的zset和hash等数据结构, 在同时需求高性能和大数据的条件下, 作为Redis的替代方案.

分布式

因为SSDB的最初目的是替代Redis, 所以SSDB会经常和Redis进行比较. 我们知道, Redis是经常的"主-从"架构, 虽然可以得到负载均衡以及数据跨地域备份的功能, 但无法实现高可用性. 考虑这种情况, Redis的主和从分别在两个IDC机房, 当主所在的机房出现故障时, 整个服务其实就相当于停止了. 因为所有写操作都失败, 而应用一般不会实现自动降级服务.

而SSDB支持"双主"架构(SSDB分布式架构: https://github.com/ideawu/ssdb/wiki/Replication), 两个或者更多的主服务器. 当其中一部分出现故障时, 剩余的主服务器仍然能正常接受写请求, 从而保证服务正常可用, 再将DNS解析修改之后, 就能在机房故障后立即恢复100%可用.

实际应用

SSDB最先在"IT牛人博客聚合网站"进行尝试应用, 接着在360游戏部门得到大规模应用, 目前支撑的数据量已经达到数百G. 这些应用最初使用Redis, 迁移到SSDB的成本非常低, 涉及的代码改动极小.

你可以拿SSDB的PHP API文档和Redis的PHP API文档进行对比.

SSDB开源数据库项目地址: https://github.com/ideawu/ssdb

我在公司介绍的"高性能并发网络服务器设计与实现"PPT.