leveldb顺序存取的效率也很高，
可当消息队列使用吗？ 和真正使用消息队列功能上有啥区别
activemq + leveldb + zookeeper集群。
性能可靠性都有了。
最近也在设计自己的SOA框架，这个问题探讨一下。
关于消息队列的技术选型，首先我们要搞清楚一个好的消息队列需要有哪些特征，然后再了解leveldb有哪些特点，是否能满足这些特征。
那么逐条看看吧：
消息队列需要支持远程访问
为什么？
因为作为一个消息队列，很有可能为多个服务提供消息，而一般情况下，生产环境中多个服务是部署在多个不同服务器（虚拟机）上的，因此只有提供远程访问的能力才能同时服务于多个服务。
而据我所知，单纯的leveldb只是一个库文件，并没有包装成一个server，你需要做一些额外的工作
消息队列需要有数据持久化的能力
为什么？
因为消息很重要，不能因为消息队列crash或者重启导致待处理消息丢失，这一点，貌似leveldb支持的
消息队列需要能保证消息送达
为什么？
消息队列必须确保消息被某个服务接收，才能将该消息从队列中移除，这一点貌似和leveldb没什么关系
消息队列必须保证一个消息只被送达一次
为什么？
我可以说不解释么？leveldb一次只允许一个进程读取一个库，看上去天生支持啊
消息队列必须保证消息顺序送达
为什么？
所谓队列就是FIFO的数据结构，这一点看上去和leveldb也没多大关系
消息队列必须提供冗余服务
为什么？
不管是高可用性，还是可扩展性，我们都希望可以通过动态的增加一个节点来解决问题。。毕竟新增一台虚拟机的成本是很小的，这一点leveldb貌似搞不定啊，原因同1
消息队列需要提供缓冲能力
为什么？
想要写入消息的服务不可能等着队列中的消息都要被处理完了（或者消息队列有固定的大小，满了就不能写入了）才能写入新消息吧，废话么。。我们需要leveldb这种KV数据库不就是为了干这个的啊
还有好多。。。但是我觉得没必要写了。。
总结：我个人觉得，leveldb并不是很适合用来实现消息队列 ，你需要做的事情太多了，包装成服务，实现多个节点的冗余，还要能监控节点状态，动态切换等等。
除开工程相关的考虑，leveldb本身的特点也值得商榷，（从互联网上了解，非我本人亲测，如果有错误，概不负责），leveldb适合多写入，少读取的应用场景，而且，如果key超过32k，性能会急剧下降。
最后，个人比较推荐Reids。。。当然，我也希望能看到你用leveldb搞定，多一种解决方案总是好的！