记一次使用共享单车的糟糕体验，讨论一下从业务流程上如何避免此类事故的发生

事件经过

今晚下班打算骑共享单车回家，但是未能成功开锁，在一段时间的等待后，APP 提示网络错误。

看到周围很多人也在扫该品牌共享单车，但是无一成功，看来是单车服务出现了故障，于是我打算改为步行回家。然而步行十分钟以后，再次打开 APP，发现我的状态是骑行中。没办法，只好折返去找那辆车，但不出我所料，那辆车已经不在原地了，大概率是被别人骑走了。

于是我在 APP 中寻找相应问题的处理流程，但是没有找到。最接近的选项是 "扫码锁未开但已开始计费"，这个选项会将我带到报修页面，但报修提交后仍需要手动关锁，且 "强制关锁" 选项仅用于处理 "关锁后未结束计费" ，并要求对有问题的锁环拍照。

这种情况下，人工客服介入是很有必要的。但 APP 里并没有接入人工客服的入口，机器人客服也只能展示那几个常见的问题选项。此时，问题陷入了一个死局，摆在面前的只有一条路，强制关锁，上传报错截图，并说明问题。但这个操作是不规范的，实际上并没有关锁，审核人员多半不会相信我的说辞，判定为忘记关锁，面临高额罚款的同时，还有可能影响个人信用。到时候想要维权也很难举证。即使是调路边摄像头，也不一定看得出锁开没开。

不知不觉中，一个多小时过去了，正在我准备点强制关锁时，APP 提示骑行结束。应该是骑走这辆车的人关了锁。此次事故有惊无险地结束了，但它浪费了我宝贵的休息时间，也暴露出了该品牌单车业务上存在的缺陷。

问题分析

事故发生后应该有所思考，是什么导致了事故的发生。如果我要搞共享单车的开发，我又应该如何避免此类事故的发生呢？

第一种可能：开锁请求失败，但用户点击 "我知道了" 之后，客户端又自动重新尝试发起请求。后续的请求成功，车开锁。这种业务流程显然是不合理的，我认为这种规模的公司不会犯这样的低级错误。

第二种可能：请求是异步的。先发起开锁请求，然后不断轮询，等待服务端更新开锁状态。开锁的请求发送成功，但由于某些原因，后续的轮询请求没有得到服务端的及时响应。而由于车锁没有打开，说明单车没有收到服务端的开锁请求，这有可能是因为网络故障，有可能是开锁请求还在消息队列中排队，也有可能两者都是。但一段时间后，服务恢复正常，车锁成功打开，客户端也成功从服务端得到了状态更新。

解决方案讨论

虽然不是内部人员，不了解实现细节，但大致可以认为是上面说的第二种可能。基于这种假设，我认为从两方面可以改进：

首先是客户端的文案。当告知用户 "开锁失败"，应该意味着客户端和服务端都已经确认了这次失败，用户可以选择放心地离开去做其他的事情，或者重新尝试开锁。所以如果开锁的请求成功，但在轮询开锁状态时没有得到服务端的响应，应该告诉用户 "服务忙，请耐心等待"，同时页面应保持不可交互，直到服务端响应。这样，用户知道自己的操作处于一个中间状态，过一会儿车锁可能会开，因此会更多地选择等待，而不是离开。

其次，服务端也应该考虑到这样的特殊情况。消息队列中的消息时效应该合理设置。现实中没有人会愿意为一辆共享单车等好几分钟，所以当一条开锁的消息在队列中积压了超过一分钟甚至半分钟未被消费（如果有消费失败重新入队的机制，这个起始时间应该从首次入队算起），就应该抛弃掉。

如果上面这两件事能做好，基本上就不会出现锁开了而人不在的情况。

有关客服

好歹也算半个大厂，竟然连人工客服的入口也没有。当年用过的其他几款现在已经凉了的共享单车，虽然排队时间长，服务质量也参差不齐，但至少可以接入人工客服。在遇到无法自助处理的紧急问题时，不至于陷入僵局。

also24

2020-06-10 01:49:03 +08:00

有一种开锁方案是基于短信的（我不太确定当前单车厂商是否仍在使用）

以速度排序，常见的开锁方式：
1 、服务端下发短效开锁密钥，手机客户端使用 BLE 方式直接开锁。
开锁成功 / 失败信息，手机和车锁均会返回给服务端。

优点：因为服务端只需要下发密钥给手机，开锁速度贼快
缺点：需要构建密钥机制，存在一定风险，智能锁需要具备 BLE 功能

2 、车锁通过 GPRS 等信道进行长连接 / 长轮询 / 轮询，根据轮询到的结果执行指令。
开锁成功 / 失败信息，由车锁通过网络返回给服务端，可以直接在长连接里，也可以是单独的 Web API 。

优点：低物料成本、低开发成本，能覆盖绝大部分场景
缺点：长连接可靠性差，容易退化为轮询导致开锁用时更长，由于连接可靠性差，可能会丢失信息，需要设计相应机制。

3 、服务端直接通过发送短信的方式将开锁信息下发给车锁，车锁收到信息时立即执行指令。
开锁成功 / 失败信息，由车锁通过类似的短信 / DTMF 通道返回，或者通过 Web API 返回。

优点：超强的"可靠性"，能打电话发短信的信号就足够，网络方面成本最低。
缺点：已经发出的短信，完全不受自己控制。短信延迟也完全不受自己控制。可承载的数据量很小。

以上几种开锁方式里，1 、2 两种，开锁任务是可以在消息队列进行管理的。
想要取消一个开锁任务，只需要保证车锁端获取不到即可。

但是 3 就很烦人了，短信形式的开锁指令，你发出去以后压根不知道车锁会什么时候收到。
如果运气不好恰好短信延迟了 3 分钟，就会出现车锁响应了 3 分钟前的开锁指令的情况。
理论上来说，此时应该可以通过让短信中携带失效时间来保证任务不会被超期执行。
但是问题来了：车锁是否具备校时的能力呢？

因为情况 3 是数据网络不好时出现的，那先排除掉基于数据网络的 NTP 服务，
印象中 CDMA 和 GSM 都有授时功能，但是似乎是看运营商的实现的。
所以这里我认为车锁并不能 "稳定的" 进行校时。

综上，消息队列的正确处理，确实能够解决 1 、2 两种场景。
但是对于场景 3，还是有一些困难需要克服。

also24

2020-06-10 01:56:51 +08:00

补充一下，关于场景 3，其实还有一种解决方案是：
当用户被通知开锁失败，点击『我知道了』按钮时，再发送一条『取消开锁』信息。

但这仍然无法做到『可靠』：

问题 1 、短信的收取顺序可能与发送顺序并不一致。

如果需要解决，就需要设定一定的缓存机制，当收到『取消 30#开锁请求』的短信，却又没有找到『 30# 开锁请求』的时候，将取消请求暂时缓存，直到收到相应的开锁请求或者超时再删除。

问题 2 、开锁是个很快速的，而且『开弓没有回头箭』的操作。
共享单车车锁的一个特点就是，可以通过电信号控制打开，但不能通过电信号控制上锁。
那么即便是两条短信相继收到，只要中间的时间差不是极小，那么收到取消请求时，开锁指令已经执行完毕，无法撤销了。

如果要解决，可能就需要在收到开锁指令的时候，设立『冷静期』，例如 10 秒后再开锁，但是这样操作好像又让用户多等了不少时间。