关于 ofo

昨天看到大佬们讨论摩拜和 ofo 谁会成，马化腾提到 ofo 使用的是 token 锁。又想起来半年前和同事们讨论过 ofo 这种离线的会变化的锁密码是怎么实现的。那时候也没有细想，不过现在看着 token 锁这个词。。想起来之前写过的这一篇：关于token。原理应该都是一样的。

这里我们假装 geek。用上一篇讲的 token 原理可以很简单地设计出一套 ofo 这样的系统。先来看看 ofo 的系统有哪些组成要件：

车牌号
二维码
服务端返回的 token 值
车锁的密码
app
其它

车牌号

对人类来说的车辆唯一标识。

二维码

这里面肯定存了车辆的唯一标识，当然了如果你要拿车牌号来当唯一标识也可以。。

服务端返回的 token 值

这个原理和 google authenticator 类似，举个例子，服务器端可以通过类似 google authenticator 的算法，用下面的脚本来生成 token：

import pyotp
totp = pyotp.TOTP("2SVVV5X3W4DJWBCX")
print("Current OTP:", totp.now())

这个算法生成的是 6 位数字，如果我们需要四位，那把前两位扔掉就好。

车锁的密码

我们平常用的 token 一般会选择基于时间的模式，不过也有基于 counter 的模式，这里先假设我们就是基于时间的。在车锁内则需要有一个简单的嵌入式芯片和简单的时钟。特意去淘宝查询了一下，这种时钟模块也就几块人民币。至于这个芯片，因为算法是固定的，我们甚至可以直接把算法焊死在电路上，什么可编程都给我去死吧。这样一个支持时钟的 C 端 token 生成器就完成了。

只要保证时钟问题不大，token 算法和 server 端一致，那两边计算出的 token 就能够始终保持一致。实际上这里的时钟稍微偏差个三五秒的也没关系。又不是手表，不需要那么精准。

app

app 负责扫码，识别出二维码中的车辆唯一标识，去服务器端查询当前车辆的 token 并返回给用户。

另外还需要负责在还车后支付(因为没骑过，我也不清楚是在啥时候支付的)。

另外可能还会负责跟踪车辆轨迹的移动(实际是用户的移动)，上报给服务端。

其它

除了上述基本模块，在服务器端是像其它 token 类应用那样存储分发出去的 key 的。例如核心的 id => key 表设计可能下面这样的：

+-----------+-------------+------+-----+---------+-------+
| Field     | Type        | Null | Key | Default | Extra |
+-----------+-------------+------+-----+---------+-------+
| id        | bigint(20)  | NO  |     | 0       |       |
| token_key | varchar(30) | NO  |     | ''      |       |
+-----------+-------------+------+-----+---------+-------+

就这么简单~

另外需要考虑的是服务端最重要的 token 查询接口，这个接口的安全性一定要做好。如果 token 锁分发出去的 key 没有办法更改的话，那么如果这个接口的数据被爬，那就相当于可以离线计算出所有车锁的密码。