[已回复] 关于MobileIMSDK里的msgId生成疑问

目前MobileMSDK中消息发送，QoS是由客户端生成的指纹（即Protocal.java中的fp属性），客户端和服务器根据fp来判断消息是否重发和ACK。
但看了些贴子，分布式部署的IM消息ID（例如：Twitter的分布式自增ID算法Snowflake）应该由服务器生成，


那么我的疑问是：
fp和msgId是指的同一个东西吗，都是消息的唯一标识？
如果fp和msgId是同一个意思：
由服务器生成，那么客户端发送时没有fp，那么怎么来判断消息的唯一做QoS和ACK？
由客户端生成，如果由客户端生成除了GUID，像Snowflake算法（放在服务器可以）也不能保存唯一。


如果fp和msgId不是同一个意思：
那么两个都存在，fp和msgId各用来干什么，fp用来QoS和ACK？msgId呢？

你说的是网红沈剑写的那篇分布式id生成的文章吧。

我的理解是MobileIMSDK里的fp其实就是他文章里说的msgId，只不过他关注的场景可能不需要像IM这种（至少MobileIMSDK里的算法是这样）需要客户端来实现QoS的场景，所以强调只有服务端生id的情况。

但不管怎么说，扯为扯去，任何id方案的基本目的都是要保证id不碰撞（不重复），MobileIMSDK里选择的uuid理论上是不可能碰撞的，但uuid的缺点就是不利于大量数据的查询性能（但MobileIMSDK里基本不存在这种情况，因为QoS在客户端做，而单个客户端自已的QoS的消息存量不可能有多大——因为谁发消息会有那么快？所以即使hash查找的性能也不会有什么损失），而沈的文章里纠结来纠结去的目的就是要找到性能好、又短、又不重复的方案。

我说的可能比较乱，但我的意见是任何方案都应该立足于自已的场景，适合的就是最好的，没必要盲目追求高大上的方案，费力不讨好。

有时间你可以下载微信的本地数据库研究下它的msgId，微信的消息id有两个：一个是本地id（我认为是本地存储时生成的，便于提升sqlite查询性能）、一个是serverId（这个应该就是你理解的msgId了），看微信的这个serverId跟Twitter的snowflake算法生成的很像（或许可能是微信改进后的算法了，我猜可能是这样），这个算法我也用过，生成的差不多就是这么大这么长的long型数字。微信sqlite样本下载地址：http://www.52im.net/thread-710-1-1.html