要保证websocket消息不丢失，需要保证各个环节的稳定，假设消息发送是这样的：ClientA => Server => ClientB 客户端A发送一条消息到服务器，服务器再转发给客户端B。这样的话，第一，需要先保证ClientA本身从操作界面点击发送，到调用服务端发送接口正常；第二，需要保证ClientA到Server发送正常；第三，Server内部处理到转发正常；第四，Server到ClientB正常；第五，ClientB接收后内部处理正常。
保证ClientA本身从操作界面点击发送，到调用服务端发送接口正常。这个环节主要针对受网络不稳定、服务器出错处理做些处理。首先，消息发送失败设定自动重发机制，然后，自动重发超过限定次数后还是失败视图呈现发送失败状态并给出主动重发按钮，最后，还需要给发送接口一个超时限制。
保证ClientA到Server发送正常;Server到ClientB正常。这两个环节针对发出方（这里指ClientA、Server）已发出，但接收方(这里指ClientB)由于一些原因无法成功接收做出处理。比如，Server已经发出消息，但是ClientB断网或者Crash了，这里Server无法判断ClientB是否成功接收，及时使用心跳技术如果没有返回则认为对方无法正常接收消息了，但是从上一次心跳正常回应到下一次发现心跳无返回这段时间间隔会有数条消息发送出去，Server不清楚这期间哪些消息是失败的。断网和crash是非常常见的问题，那么需要怎么避免呢？可以建立一个Ack机制，接收者接收成功后再回复一条消息告知发送方。在有Ack机制的情况下如果接收方出现断网或者crash时，发送者就无法收到接收方的回复，这是发送这可以设置如果超过一定时间没有Ack则重新发送一次，重发机制在ClientA => Server和Server => ClientB处理上会有一些差别，ClientA => Server重发几次失败后可以通过视图告诉客户，并指导客户手动重发，Server => ClientB则重发几次失败后需要保存下来在合适的节点（ClientB的websocket重连）再次重发。
Server内部处理到转发正常。题主从事前端方面工作这里不讨论。
ClientB接收后内部处理正常。这个环节主要针对crash做处理，接收到Server的消息后及时存储并在成功存储后再对Server做Ack，这样在没有及时存储情况下crash还可以再次利用Server重发机制收到消息，不会导致丢失。