我正在用MongoDB支持一个实时websocket服务器应用程序.
客户群正在增长，单线程性能已经不够.我需要一个发布/订阅层来跨线程分发消息.
我通常会 Select Redis，但由于应用程序已经使用MongoDB，我可以使用可定制的游标避免依赖性.然而，我担心性能.
MongoDB的可定制游标性能与Redis在pub/sub架构中的性能相比如何？
我正在用MongoDB支持一个实时websocket服务器应用程序.
客户群正在增长，单线程性能已经不够.我需要一个发布/订阅层来跨线程分发消息.
我通常会 Select Redis，但由于应用程序已经使用MongoDB，我可以使用可定制的游标避免依赖性.然而，我担心性能.
MongoDB的可定制游标性能与Redis在pub/sub架构中的性能相比如何？
实际上，它们是非常不同的动物.
MongoDB可裁剪光标的工作方式有点像队列.它可以与封顶集合一起使用，因此您不必显式删除集合中的项.它非常有效，但请记住，MongoDB会在每次写入操作时锁定整个集合(实际上是数据库)，因此它限制了可伸缩性.另一个可伸缩性限制是连接数.每个客户端连接都会在mongod服务器(或mongos)中添加一个连接线程.
尽管如此，你仍然可以期望每秒有数万个项目没有重大问题，这对于一系列应用来说已经足够了.
另一方面，Redis通常可以同时处理更多的连接，因 for each 连接不创建线程(Redis是一个单线程事件循环).它的CPU效率也非常高，因为它不会在所有项目上排队.使用Redis pub/sub，项目将在与发布相同的事件循环迭代中传播到订阅服务器.这些项目甚至没有存储在内存中，Redis甚至没有一个单独的索引需要维护.它们只能从一个套接字缓冲区中检索，并被推入另一个套接字缓冲区.
然而，由于没有排队，Redis发布/订阅消息的传递根本无法保证.如果发布消息时订阅服务器关闭，则该订阅服务器的消息将丢失.
有了Redis，你可以在一个内核上每秒看到数十万个项目，尤其是如果你使用流水线和多个发布客户端的话.