前言:

       高性能队列?  golang channel 可以理解为一个高性能的队列。但他毕竟是基于内存的，如果因各种情况堆积任务，可能会被oom，怎么办?  除去业务上的优化，看看是否有别的选择?  什么redis ?  redis3.x之后倒是有个虚拟磁盘技术，除去内存外，还可以使用磁盘，但性能太差。 Rabbitmq堆积后速度也很慢，慢主要是因为他的持久化分片设计问题，后续有时间跟大家唠唠。 持久化的队列选型其实可以选择kafka，但很多时候我又不喜欢多引入一个中间件。

      话说，不管是python还是golang，不管是原生或者社区都没有太好用的持久化队列库包，这里说的是直接可引入库像sqlite库那样，而不是消息队列服务端。 

      先前在github中找到一些golang的队列实现，但不合心意，不是性能太差，就是实现太丑，还有使用不友好。 借鉴了这些所谓经验，开发了一个高性能队列，代码我已经推到github中，有兴趣的朋友可以试试. https://github.com/rfyiamcool/rocks_queue

该文章后续会有更新， 原文地址 http://xiaorui.cc/?p=4942

队列的设计原理

我先前写过一篇文章来阐述过 现在市面上的持久化队列的设计原理，方案不外乎就几种: 

一种是类似redis的方案，日志先行，通过后面的cow机制来重新覆盖日志文件，这样避免日志文件过大… 

一种是类似kafka 分区方案，设计逻辑信息id, 然后进行分区，每个分区里有一堆的数据文件及索引文件，每个索引可以二分的查找具体id的偏移量位置.

一种是基于lsm引擎设计的nosql来扩展队列模型,  就是我现在采用的模式.  社区里现在lsm引擎数数据库比较热的有 leveldb, rocksdb . 市面上不少公司是使用rocksdb来设计的nosql，像ssdb，ardb, 360 pika, pingcap的tidb…  

rocksdb只有kv模型，我们如何通过kv模型来构建双端链表的模型？ 可以看下面的设计模式…

表明类型为list队列

    key                               value

+queue_name,l                           1
list数据存储格式

                key                                    value

l[queue_name]\x01\x00\x00\x00\x00\x00\x00\x03   xiaorui.cc index: 945
l[queue_name]\x01\x00\x00\x00\x00\x00\x00\x03   xiaorui.cc index: 946
l[queue_name]\x01\x00\x00\x00\x00\x00\x00\x03   xiaorui.cc index: 947
l[queue_name]\x01\x00\x00\x00\x00\x00\x00\x03   xiaorui.cc index: 948
l[queue_name]\x01\x00\x00\x00\x00\x00\x00\x03   xiaorui.cc index: 949
l[queue_name]\x01\x00\x00\x00\x00\x00\x00\x03   xiaorui.cc index: 950

怎么用

首先安装rocksdb存储引擎

https://github.com/facebook/rocksdb/blob/master/INSTALL.md

测试样例代码

git clone git@github.com:rfyiamcool/rocks_queue.git
cd rocks_queue
go run main.go

性能如何

使用固态硬盘ssd, 不加载tcp模块，直接单纯的库引用的模型下，每秒可以插入19w数据，每秒可以get 18w的数据。 限于机械硬盘的io能力，插入读取也就8w左右…

参考了约炮神器陌陌 { GoRedis半成品代码 }

END…