所谓的小红点，我们用最简单的场景来看的话就是我们手机app外的小红点数量。
如果需要进行小红点数量控制，那么就会涉及到几个点。
首先，需要确定：哪些消息是属于小红点需要管理的消息。
其次，还需要确认：消息已读的机制。
确定这两个点，那么基本上小红点的需求就基本明确了。
那么，现在我们来看下tophy的小红点机制。
注意：这里不对应用内的消息角标数量进行处理。
目前Tophy只对Ios端应用角标消息的控制，安卓由于系统多样且难以控制暂时不考虑。
Ios端打开App后会使用应用内的消息数量覆写应用角标数量。
因为这里不处理系统通知和官方助手，所以会出现应用角标数量和app内的消息数量不一致的情况
目前由于只有私聊消息会进行应用外角标数量的处理，所以目前的已读机制也是特例化的，依托于会话的已读。
基本逻辑：对已读会话的未读数量进行已读操作，那么新的应用角标数量=当前应用角标的数量-已读的消息数量
同时，客户端会覆写应用角标数量
在功能设计方面，主要的逻辑操作放在数据层（dpg-data），对外以RPC接口暴露操作。
由于并不需要保证小红点数量的同步性以及准确性（不需要特别精准），意味着不需要过多的异常补充措施。
目前，我们需求只需要小红点的数量，但是也需要预留接口进行具体【小红点对应的消息】的存储。
架构如下图：
RedDotService.redDotDataSupport(StringuserId,RedOperEnumredOperEnum)
THE END