有这么一个企业应用的需求，底层数据的变动会触发一个事件，这个事件需要发送给订阅的用户。用户主要是在上线时（打开页面时）拉取属于自己的信息（严格按时序排列）。如果将所有这些事件利用系统会话发送给指定的用户（一个事件可能需要发送给10~100个用户），就会产生大量的系统会话记录（比如每秒上千个事件），一年有估计几十到几百个million。在这种场景下，每个用户上线时去拉取属于自己的信息，会不会遇到性能下降的情形？

我们在考虑是自己搭建一个基于kafka的消息系统，还是采用leanmessage，请不吝赐教。如果能够提供Leanmessage后台的机制更加感谢（比如系统会话的索引机制，或者是否考虑为每个用户作一个拉取信息用的队列，类似微信朋友圈）

感谢回复！
其实我担心的正是“而是分批的一批一批从新到旧的拉取消息”时，leanmessage后面采用的索引机制是什么，这种索引机制是否能够从理论上保证“性能并不会因为数据量的增长而出现大幅变化的。” 如传统数据库，即使采用了索引，当数据量增大到一定程度上的时候，索引查询的性能也会逐渐下降（索引也会越来越大）。

好的,多谢,我们先尝试下!
但是....系统会话消息的发送和下发...只能使用REST API...这是什么原因? 我们还是希望使用SDK,因为我们打算是在客户端和系统会话之间做一层缓存,比如用LeanCache，将用户最近100条消息缓存起来，所以用SDK做中间的处理会比较方便，用REST太别扭了。

另外系统会话还有to_peers不能够超过20个的限制，也是头痛

多谢您的及时回复！

实际上我们也在想这个问题，是不是可以用普通会话。主要考虑的问题是，每一条消息（事件）要送达的用户对象都是动态的（用户可以随时订阅和退订事件，比如#1消息发送给用户A，B，C，#2消息发送给用户C， D， E），用普通会话就需要动态的管理会话成员，或者需要为每一个事件都建立一个普通会话。所以，感觉上如果都是发送10,000条消息的话， “在一个系统会话上发送10,000个消息”，似乎要比“建立10,000个普通会话但是每个会话只有一条消息”要合理的多。

或者建立一个普通会话把所有的用户都加为成员（每次新用户注册都要加入这个会话）？这样也不对啊，这样每条消息这个会话内的所有用户都可以收到阿