idea's blog

经过半个用的开发和测试, 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

在 socket connect/bind 所使用 sockaddr_in, 一定要记得 bzero...

struct sockaddr_in addr;
bzero(&addr, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_port = htons(port);
inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr);

因为 sockaddr_in 的定义是

struct in_addr {
  in_addr_t   s_addr;           /* 32-bit IPv4 address */
                                /* network byte ordered */
};

struct sockaddr_in {
  uint8_t         sin_len;      /* length of structure (16) */
  sa_family_t     sin_family;   /* AF_INET */
  in_port_t       sin_port;     /* 16-bit TCP or UDP port number */
                                /* network byte ordered */
  struct in_addr  sin_addr;     /* 32-bit IPv4 address */
                                /* network byte ordered */
  char            sin_zero[8];  /* unused */
};

可能, bind() 函数要求 sin_zero 必须全清空为 0.

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 一直保持的稳定的更新速度, 代码在完善, 功能在丰富和整合. 目前已经有多个国内和国外用户在尝试使用, 相信很快就可以成为 SSDB 的正式用户.

前几个版本, SSDB 增加了 log rotate 功能. 最新的更新版本中增加了 hlist 和 zlist 命令, 用于列出当前的 map 和 zset. KV 结构的数据仍然使用 keys 列出. *list 既不同于 *keys, 也不同于 *scan, 因为 *list 用于列出集合的名字, 而后两者则用于列出集合的内容.

最近 SSDB 在生产环境的使用中, 遇到了多机房的问题. 在机房间网络无法改善的情况下, SSDB 必须能应付这种状况. 这里初步设计了新的同步体系, 欢迎大家一起讨论: https://github.com/ideawu/ssdb/issues/11.

据说 github 功能更强大更适合多人协作开发, 所以我把 SSDB 从 Google Code 上迁移到了 github. 目前正在体验当中, 能想到的 github 的一个好处是, 我可以 fork 一个项目出来, 作为基于 SSDB(LevelDB) 的分布式存储项目, SSDB 仍然作为单机和简单主从结构的存储服务器项目.

项目地址: https://github.com/ideawu/ssdb