@documentzhangx66 你讲的我明白了，你这个是实现 ack 机制

@Building 你这样讲我大概清楚了，至于更细节的操作，我和前端同学沟通下

谢谢各位了

@documentzhangx66 设置这四个字段的深意我现在还不太理解。

@Building 对，但是这里边有个点我没太明白，比如上线后，在线消息，直接推送本地，保存 sqlite 。同时起个线程，根据 seq 倒序拉数据到 sqlite 。然后主线程从 sqlite 取上翻数据是这样的吗？

这个文章是如何优雅的实现大量离线消息的可靠投递 和楼上的想呼应的。但是还是没解决我的问题。https://segmentfault.com/a/1190000023318638

可以理解为单单通过 seq 可以获取最新的消息标识，但是无法区分离线消息是否已经被拉取完毕。

欢迎回来

@giiiiiithub 腾讯的售后服务一直蛮好的

我现在想确定的点，其实是怎么定位到问题，是什么导致 udp 打满的。

明白了，谢谢大家。

我现在直接放弃 docker 安装了，直接安装在环境中

没有用，任何操作都是卡在操作页面。

纯粹的 restful api 不能完美的符合业务侧的需求。
get 和 post 的使用更多的是根据业务来考虑。

全部使用 post 坏处是查操作，以及打日志方面处理起来增加了负担。
好处吗，比如传递参数没有限制。

好的，谢谢大家

我先压测下关于频繁更新的行锁情况吧。这个很靠谱的。

类似于客观锁这种机制，所带来问题就是用户操作的失败。
这从代码层面其实没有太大问题，但是对于产品侧，用户体验方面，这个问题就比较严重。
如果乐观锁校验失败，这个就更新失败。

业务场景就是用户之间赠送礼物，比如同一秒多个用户给一个用户 A 送礼物。
如果这时候加行锁的话，用户这条记录就被锁定了。
问题就在于用户这张数据表属于热表，该条记录的其他字段在其他业务也有更新操作。
担心行锁的话，就会出现死锁的情况。

更可怕的一点，我们这边是主从库配置，现在我暂时把代码切换成查主库，可以降低该概率的发生。
现在对用户操作，都有日志记录。

既然如此，现在我能发现问题，但是对于怎么成本最小的解决这个问题，或者优化这个问题，现在没有太大思路。

恭喜

谢谢

洗诶写