• 2014-02-10

    百行代码实现一个简单的Zset(SortedSet)

    Views: 20630 | 5 Comments

    排序的集合(Zset, SortedSet)是这样的一种集合数据结构, 集合中的元素不可重复, 而且元素之间根据每一个元素的权重来排序. Zset 是一种非常重要和应用广泛的数据结构, 是 Redis 数据库所支持的最核心一种. Zset 可用于排行榜, 好友列表, 去重, 历史记录等业务需求. 你可以理解一个 Zset 是一个下面结构的数据库表:

    item,   score
    UNIQUE, INDEX(int)
    

    Item 列被加了 UNIQUE 约束, 所以可以去重. Score 列是加了索引的整数列, 可用于排序.

    如果要在内存中实现一个 Zset 数据结构, 我们可以看 Redis 的源码.

    Continue reading »

    Posted by ideawu at 2014-02-10 20:28:11 Tags:
  • 2014-02-10

    Mac 奇怪的打开文件操作变复制打开文件操作

    Views: 6710 | No Comments

    最近, 我的 Mac 操作遇到一个诡异的行为. 有一个文件, 每次我在 Finder 里双击打开它时, 都会在同目录下生成一个新的 Copy 文件, 相当于打开操作变成了复制并打开.

    我尝试改文件名, 更改打开方式, 都不行. 后来在文件信息里发现"样板"(Stationery pad)这个选项是选中状态的. 将这个选中去掉, 就OK了.

    在网上一查, 原来这个选项就是把文件变成模板, 双击打开时, 就是复制出一个新的文件, 然后再打开. 这其实是一个毫无意义的功能.

    Posted by ideawu at 12:32:06
  • 2014-02-10

    结合IO多路复用的多线程服务器模型

    Views: 22778 | 3 Comments

    IO 多路复用技术, 就是常说的 select/epoll/kqueue 等处理文件描述符相关的函数. 在高性能高并发网络服务器的实现时, IO 多路复用技术可以用来处理多个 socket 连接的读写 IO 操作, 避免了传统的每一个 socket 连接分配一个单独的线程的低效的多线程技术.

    虽然多线程在处理高并发网络 IO 方面是低效的, 但是, 多线程在处理业务相关的逻辑方面是有优势的, 而且多线程能利用多核 CPU.

    所以, 一个高性能高并发的网络服务器, 应该是结合了 IO 多路复用技术和多线程技术的.

    IO 多路复用技术用于处理网络 IO, 而多线程用于处理业务逻辑. 那么, 这两种技术是如何结合的呢?

    整个服务器的流程是这样的: IO 多路复用接口层从客户端 socket 中读取了完整的请求报文之后, 便将请求报文转交给线程池, 线程处理完业务逻辑, 生成响应报文, 转交给 IO 多路复用接口层, 发送给客户端. 示意图如下:

            bytes                         packet
    Client ------- IO Multiplexing Layer -------- Thread Pool
    

    这样, 一个重要的问题就来了. 线程池和 IO 多路复用层之间的交互是报文(其实就是内存操作), 但是, IO 多路复用层只能处理文件描述符, 也就是 read()/write() 系统调用. 因此, 两者的交互必须从报文传递转换成文件描述符的操作. 所以, 我们需要一个可以 select/epoll/kqueue 的队列.

    为此, 我用管道(pipe)封装了一个 SelectableQueue 类, 可以和 IO 多路复用层无缝结合. 这个技术已经在 SSDB 数据库服务器中使用了, 感兴趣的朋友可以获取 SSDB 的源码看看.

    唯一的不足是, 管道通信在 10us 左右的延时, 所以会影响单个请求的处理时间, 但是, 对于高并发的网络服务器来说, 单个请求的处理时间的微小增加, 并不会对整个服务器的吞吐量有明显影响, 所以整个服务器的处理能力仍然非常高.

    Posted by ideawu at 10:54:31
  • 2013-11-20

    Facebook rocksdb 的网络服务器支持

    Views: 31351 | No Comments

    前几天, 我初探了 Facebook 开源的 rocksdb, 一个据称比 Google leveldb 性能强劲数倍的 KV 存储引擎. 虽然 rocksdb 提供了压测数据, 不过对于 rocksdb 是否名副其实, 以及它在不同的应用场景下有什么特点, 有没有坑, 我还是保留疑问的.

    为此, 需要对我们常见的使用的场景也做压测. 首先, 必须给 rocksdb 封装网络支持, 也即 client-server(C/S) 支持. 我直接使用了 ssdb 的源码, 几乎很少的代码改动就运行起来了. 因为 rocksdb 本来就是基于 leveldb 的, 函数名都几乎一样.

    我直接使用 ssdb 的源码对 rocksdb 进行封装, 也是考虑和原来的 ssdb 做对比. 稍微透露一下, 在空库的条件下测试, rocksdb 作为存储引擎时的性能比使用 leveldb 时有所下降. 不过, rocksdb 的官方测试数据都是在超过 RAM 的大数据场景下测的, 所以接下来, 我还要对各种场景进行测试.

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

    Posted by ideawu at 2013-11-20 00:38:24 Tags: ,
  • 2013-11-17

    性能超越 Redis 的 NoSQL 数据库 SSDB

    Views: 50095 | 34 Comments

    SSDB 是一个 C++ 开发的 NoSQL 数据库, 使用 Google 公司开源的 LevelDB 引擎作为底层的存储引擎. Redis 是一个 C 语言开发的内存 NoSQL 数据库.

    Redis 非常流行, 不仅仅是因为其高性能和可持久化的特点, 还因为它支持丰富的数据结构, 能很好的表达业务模型. Redis 的国内属新浪应用比较广泛.

    但是, Redis 的缺点也很明显, 那就是它的内存数据库模型. 所有数据都存在内存中, 即使最有钱的互联网公司, 也没法承受 $5000 (一台服务器, 100G 内存)固定成本, 以及持续不断的 IDC 租金成本来存储区区的 50GB 的数据, 这个成本太高了!

    SSDB 拥有 Redis 的主要优点 - 高性能, 丰富数据结构, 并且拥有 Redis 所不具备的能力 - 大数据存储能力. SSDB 服务器的单机存储能力是 Redis 的 100 倍! 因为 SSDB 能将数据存储在硬盘中.

    在使用 SSDB 自带的 ssdb-bench 工具, 以及 Redis 自带的 redis-benchmark 工具在相同机器上的测试中, SSDB 的读性能完全超过了 Redis, 这非常出乎意料. 不过, SSDB 的写性能还是比 Redis 慢了 10% 左右. 要知道, SSDB 是一个硬盘数据库, 而 Redis 是内存数据库, 后者写性能高一些是可以理解的.

    欢迎各位在自己的机器上做性能测试, 并反馈. 下面我做的测试的结果图.

    机器信息: MacBook Pro, Retina, 13-inch, Late 2012

    Continue reading »

    Posted by ideawu at 2013-11-17 22:44:56 Tags:
  • 2013-11-17

    Facebook 开源的 rocksdb 初探

    Views: 29779 | 3 Comments

    Facebook 最近开源了一个 NoSQL 存储引擎 rocksdb. 这个开源引擎是基于 Google 的 leveldb 1.5 版本, 但据称做了许多优化, 性能相对 leveldb 有了很大的提升, 而且解决了 leveldb 主动限制写的问题.

    为了试验 rocksdb 是否能应用于 ssdb, 以及换了 rocksdb 之后 ssdb 是否有明显的性能提高, 所以我下载了 rocksdb 的源码来试着编译一下.

    有几点需要注意的. 首先 rocksdb 用了 C++11 的特性, 所以需要升级你的 gcc/g++ 为 至少 4.8 版本. 编译过程还发现, rocksdb 在 Mac OS X 操作系统下无法正常编译, 尝试解决了一个问题, 又出现另一个问题. 因为官方没有考虑过这些问题, 所以暂还无法在 Mac 下使用. 所以, 我还在等待 Facebook 官方升级 rocksdb.

    所以, rocksdb 初探意外终止.

    2013-11-17 17:16 更新:

    官方已经解决了编译问题, 我将进行下一步试验.

    Posted by ideawu at 14:59:15 Tags: ,
|<<<123456789>>>| 4/12 Pages, 68 Results.