变道提前打灯
上海中环和罗山高架路上的不少电子警示牌，不厌其烦地提示着"变道请提前3秒打转向灯"，以前看到了也就看到了，因为笔者一直很守法，一般提前5秒就打了，所以此警示从未惊起什么波澜。某日清晨脑回路猛然搭住，就想如果变道不打灯被视作违章的话，这个识别的程序逻辑该怎么设计呢？
砍材不误磨刀功，不了解的领域准备工作还是要充分调研的：
大众熟知的闯红灯识别，步骤是通过路口的三个感应线圈触发摄像头的三次拍照，命中三次就视为违章，笔者开始也是想当然的认为摄像头大部分都是靠拍照。
后来跟专业的同学求证，新一代交通摄像头的工作原理其实大约是这样子的：摄像头会持续拍摄交通情况的视频，而在摄像头所在位置附近会有个本地的存储器和处理器，视频就存储在那里，而后处理器会基于图像识别或者人工智能blablabla等技术手段分析视频中的违章情况，一旦识别出就会截取视频生成图片，最后这些高清截图会上传到远程的市局服务器存储，而违章截图也是从此而来（该信息只是单方面求得，如有偏差欢迎指正）。
继续又去查了一下，汽车转向灯的频闪间隔大约是1Hz，也就是一秒钟闪烁一次，当然也有0.5秒闪烁一次的，这个汽车行业和国家并没有硬性规定。
抛开图像识别的领域不谈，剩下的实现难度在哪里呢？且让我直接写三个案例来阐明：
Case 1
变道前的4.01秒开启转向灯，到3.01秒的时候转向灯刚好熄灭，到2.01秒的时候转向灯再次亮起。
Case 2
变道前的4.99秒开启转向灯，到3.99秒的时候转向灯刚好熄灭，到2.99秒的时候转向灯再次亮起。
Case 3
需求只提到了提前3秒这个下限值，那上限值应该是多少呢？我可否提前5秒打转向，甚至提前1分钟打灯呢？很明显间隔太久的转向灯完全没有意义，所以这个需求描述是有缺陷的。
剖析解读
Case 1 & 2两个案例类似，都在3秒前打灯了所以肯定不违章，但是3秒这个时点上转向灯都是熄灭状态。视频分析所需的时间窗口当然不能卡在3秒这个时点上，那么需要放大到多少合适呢？案例1的时间窗口必须不小于3.02秒，案例2不小于4秒。注意，这里说的是时间窗口的下限。
而Case 3主要说的是时间窗口的上限，因为我不可能把时间窗口设置到无限大，按照交通实际情况，1分钟开外的转向警示基本无意义了。经查交通法规里确实没有这方面的描述，看来对于“提前”这件事情大家都知道很难量化的定义它。
再考虑一下需求设计问题：
（架构师的基本素质之一 -- 质疑需求&明确需求）
1. 是选择提前“时间”合适还是提前“距离”合适？选择“时间”就会出现上面的时间窗口临界问题。选择“距离”，在不同的车速状况下，“车速”越快打转向灯的提前距离就应该越大，若是需要再严谨些的描述，这个“车速”应该是前后车的“相对速度”，想想是不是如此？
2. 对于汽车的转向灯频闪频率国家似乎并没有一个统一标准，那就意味着有长有短，进一步造成时间窗口的不可确定性。
3. 闪烁次数前文也简单提过，基于频闪频率的最小闪烁次数也需要保证，否则连2S的时间窗口都看不到转向灯亮起过，这视频没法分析了。
另外，基于3个案例假设我们设定时间窗口为变道前的[-5s, -3s]，表示这个时间区间内必须出现过转向灯的亮起状态。如果某个极端情况转向灯在[-5s，-3s]仅亮起一次，(-3s, 0) 再也没有亮起过，也就是转向灯总共就闪了一次而已，警示作用很不明显，那么对于转向灯的最小闪烁次数是否有要求呢？经笔者对自己车子的多次测试，开启一下转向即使马上关闭，转向灯也至少闪烁3次。(对测试当日跟我车屁股后面的司机师傅们深表同情，你们可能一直在骂前面那个傻叉为什么一直在打转向？)
解决方案
透过问题看本质无非就是时间窗口的临界设定问题。
首先简单放大时间窗口这么低级的方案肯定为架构师所不齿，因为再大的时间窗口都可能会存在临界问题，而且时间窗口越大处理器分析的压力就越大。
这里我要祭出本人一直以来作为架构师灰常灰常重要但是很容易被忽视的一条原则：“能用规范化和标准化来解决的问题，就不要再花更多的成本用在工程手段上”。此原则在创业公司尤其适用。
比如费尽九牛二虎之力研发了一个元数据管理系统，可以对业务系统里各类风格迥异千奇百怪格式的日志进行解析，后果是这个元数据系统可能永远跟不上业务系统更新的速度，而你只能跟在屁股后面不停的修正这个元数据系统。如果写个日志组件，规定让所有的业务系统必须集成，直接打印出规范的统一标准的日志来，元数据系统的设计就可以相当简单了。
再比如运维耗尽全力为了实现基于容器化的持续部署，不得不为每个业务系统不统一的变量声明方式编写大量的yaml配置文件，为什么不能让业务系统统一改造成规范的变量配置方式呢？相信这才是一劳永逸且最省力的方式吧。
回到转向灯的问题上来，我的解决方案首选压根就不是技术方案，而是先把上面提到的所有不确定的问题先制定出标准来。比如闪烁频率，最少闪烁次数等。
解决方案我会用软件产品的几个典型场景来类比，让大家自己去联想吧。
银行日终跑批
银行支付类金融系统都会有日切，做一些停业记账、清算、会计日期切换等操作，而这个窗口就算时间足够的短，也不得不停止某些业务比如转账，这段时间也就是银行日切黑暗期。有的银行在晚上 9-11点，有的在凌晨1-2点，不一而足。首先对于庞大的信息系统要做好时间的完全同步和一致是基本不可能的，所以时间窗口可能产生交叉，由此出现任何的账务数据异常，都是很可怕的一件事情。
TCP的滑动窗口实现
前面描述的所有细节都是基于变道这个时点来往前倒推，如果用类似TCP的滑动窗口方式呢？比如我们就设定5秒的滑动窗口，交通摄像头我们估算一秒100帧的水平，那么5秒的窗口里就有500帧图像需要处理。对滑动窗口内的每帧图像进行识别，标示出当前转向灯亮暗的状态，当某一帧识别出变道动作，那只要把[-5s, -3s)区间内的图像识别的转向灯状态做个简单的运算即可，就算区间再大一些也完全不是问题。
当然转向灯闪烁间隔是一秒的话连续100帧图像都应该是一样的状态，如果只是做转向灯的识别那么可以把粒度放宽直接跳过其他的99帧，如果也做其他的违章识别另当别论。
随着处理器给出分析结果，窗口向后滑动，继续处理新帧和等待处理器的应答，如此循环往复。
另外，流式数据处理框架Spark Streaming也采用了滑动窗口实现方式。
Minimum Window Substring算法
最小覆盖子串算法，也是从滑动窗口延伸的一个算法，当然也有数据结构的小窍门。因为要取最小，所以也涉及到如何收缩窗口让子串最小。请考虑如何让收缩窗口让视频分析的区间更小呢？
算法讲解参见
分布式锁的临界问题
分布式锁的实现方案很多，市面上以Zookeeper, Redis实现的居多。不管是哪种，都要考虑这么一个问题：持锁的进程在释放锁之前崩溃了，导致锁一直在无法释放的状态。为了避免这种情况，一般会设置一个锁失效时间，这个时长设定一般要比99%的持锁时间久，那么就引入另一个问题，假如持锁的进程A就是不小心抖动了一下导致持锁时长超过了失效时长，而失效机制导致锁的释放就意味着进程B也可以持有这个锁。A B两个进程同时持有锁，我就问你怕不怕！我就问你慌不慌！不然的话，或者你的系统允许这种极端情况的发生，有一定的容错能力，大不了最后再补救。或者你需要一个双向的锁检测机制，客户端在逻辑链路上的关键节点不断检测锁的剩余时间，然后基于自己估算的仍需时间延长锁的失效时间，反过来，服务端也可以检测客户端的持锁时长，在超时那一刻，通知客户端必须做出锁失效/快速失败的回滚处理等等。这些细节都不是那么容易操作的，所以我也就抛出个思路，拿走不谢。
