平分很正常，但只报了你没报那个同事是什么操作？

你确定不是领导故意的？

@nleg 个人意见，如果你想在数据库内设置一个字段用来控制到 ES 的同步，那么这个字段最好不要每次同步完就改，不然这些都是额外的 IO ，毫无意义。
特别是当你 ES 的索引有问题，你需要恢复状态或者全量同步的时候，你这么搞就完全做不了了。

你这数据量如果不涉及删除的话，只要增加个 update datetime 字段就行。如果修改也不要，那就 create datetime 就够了。
每次启动的时候，ES 里面找个最大的 datetime ，然后从 mongodb 里面找所有比他大的 document ，分批拉回来就行。

这样你不管差多少数据都能同步回来，控制好批量查询和插入的速度就行了。也不用在乎什么 oplog 或者 change stream 。

“坚持运动” 就可以一直坚持下去的。

我通常会撸铁，三分化练三休一。但如果天气好或者朋友约，就会替换成户外骑行。或者有的时候也换成跑步爬楼。如果觉得今天状态不好，那就换成低强度有氧，椭圆机或者简单骑骑车。状态再差的话，就出门散散步或者做点拉伸活动一下。

除了生病发烧，基本每天都会活动活动。

不要给自己上太大的压力，也别给自己设定特别高的及格线。运动贵在坚持，只有适合自己强度的才能坚持下去。你天天 996 ，半夜下班还撸铁一小时或者跑个半马。或者加完班了还要冲个 PR ，光是想想就坚持不下来。

MongoDB 有 Change Stream ，你可以理解为 bin log 。实际上是一部分的 oplog 。

他有个 token ，你可以拿到从这个 token 以后的所有数据库变更。

但实际上是基于 oplog 的，你如果太长时间没同步，或者那个 oplog 设置很少，操作太多的话可能就给顶掉了。如果你数据的变更不太多，或者你可以大部分时间实时同步下来，那就没问题。

也有很多方案是基于全量扫描然后自己找变更的，你如果数据量不太大倒还行，数据量大了这么搞相当于增加了额外的负担。

或者你数据库本身设计的很好，每个记录都有变更时间，那你每次只刷上次变更以后的就行，比刷那个 change stream 还要靠谱一些。只是删除需要额外处理，比如并不真的删除数据，而是给个 flag ，或者移到另一个 collection 里，那用这个方法倒也能同步了。

@jadec0der 那这个成本应该就上天了。。。


@Xusually 一楼就改了

更正，是 365 天里，在这 737 的机体中门上，发现了 392 个问题。。。。

@connor123 因为全程票是优先发售的。

本质上是高峰期运力不足，如果长短乘同概率发售，那么长途旅客永远别想回家了。毕竟你一个全程 10 站的路线，只要有人买了一站，那就要有一个全程旅客回不了家。那么如果按照运力资源收费的话，占用了全程资源收个全程票也合理啊。

之前也有乘务说过，买长乘短的骂他们想多赚钱，中途上车补票的骂他们不拦着短途旅客，他们全程票买不到。
横竖都是有骂的，很多时候全看你屁股坐在哪里。你觉得你买不到短程票是不公平，长途旅客也觉得他们这种长程旅途本来就难，经常抢不到也不公平。虽说我回家就是短途，现在已经很难买到票了，但我也不觉得这不合理，毕竟那些走全程的回趟家比我更难。

所以出了候补，你短途的挂着排队，有资源了先来后到，已经是现在这种状况下最合理的解决方案了，至少我想不到更好的办法。

@connor123 12306 的候补并没有加价吧？

FlashPad
http://www.haoxg.net/tools.html#flashpad

3M 的小工具，可以代替 notepad 随手记点什么。
单文件，纯绿色版，官网有代码。

不过这就是个简单的记录工具，不支持 markdown ，也不支持滚轮字体缩放等功能。

@worldqiuzhi 只有 2016 支持 docker 又不支持 wsl ，但它也是 hyper v isolation 。还不如你 hyper v 里开个 Linux 虚拟机。

对于一个商业产品来说，“成本”并不只有开发和运行成本，也要包括审计合规，法务，数据保护等等。

而 auth 这东西就属于，你不能没有，开发起来难度也不高，但合规处理非常麻烦，想要防御针对性攻击更加麻烦，同时也不是核心的业务数据资产。
对于大多数业务模型来说，用户这东西只要是个唯一 ID 就行了，至于他叫什么名字，用什么邮箱并不是很重要。

而合规这玩意，不同国家地区的法律并不相同。虽说很多时候你的业务数据可能也算需要做合规审计的用户数据，但 auth 里面的东西一定是要做合规的。

对于一个风险很高，法务处理很麻烦，又不是很重要的东西，最好的选择自然就是外包了。
让第三方去提供各种合规审计，各种防护措施。远比你雇一整个团队去做更省成本。

没意义，Redis 本身不支持 Windows ，你装它还要用 WSL ，那就不如直接 WSL 里跑 Docker ，然后其它的全用 Docker 部署了。

如果你用的是 Redis for windows 等等的第三方版本，你可以把你所有依赖的安装包收集好，然后写个脚本挨个调用解压或者安装就行了。

更麻烦的，你自己做个大的 msi 。Windows 支持很多安装部署功能，msi 可以做到非常复杂的多组件依赖处理。就看你要不要做了。

@BeautifulSoap 同意。叫不叫 DDD 无所谓，只要比现在一锅粥的架构强，那就有实践的价值。

很多东西完全按理论走结果肯定是最好的，但成本也不一定是所有人都能接受的。包括开发成本，人员的培训成本，PM 和客户的额外沟通成本等。

比如 Restful 设计，很少会完全按照它来设计 API 。但它的思想是好的，借用到项目里能有改善，那就值得去学习和尝试。

没事，800 顶多爆玻璃，不至于掉门的。
一般来说玻璃窗爆炸还不至于停飞，除非设计上有问题，但那就不会只炸这一次了。
https://www.channelnewsasia.com/asia/japan-all-nippon-airways-flight-1182-boeing-737-cockpit-window-crack-4045796

我之前是你睡眠里设置的起床时间点如果你额外设置了个闹铃，或者某个闹铃 snooze 后和其他闹铃重叠，就会有概率不响。

所以我按质数间隔设置了好几个闹铃，反正总有一个响的。开关闹铃都用 siri ，也不用手动一个个点。

再后来就换了安卓，反正几年了没见过不响。

思维导图用 XMind
架构图只用 PlantUML ，除非要做 PPT 。

买个好点的恒温混水阀就行了

你 5W 个设备要是时钟很准，卡在同一秒上报状态的话，那就是极限状态下一秒 5W 的写操作，你那数据库分分钟就干爆了。而且你要的是“状态转换”而不是“当前状态”。
要是我的话，会做一个用来缓冲和过滤的组件，来维护这个状态，并当数据改变时再分批写入数据库。
直接做个简单的 webserver ，内存里维护一个数组。收到数据时对比一下已有数据，如果有变更就塞队列里，然后 mysql 定期从队列同步状态写回数据库。

这程序甚至都不用做持久化，每次启动的时候从数据库里读一次全局状态，或者等 30 秒后设备给你发过来就行了。

但还是同样的问题，如果你 IoT 设备时钟很准，你这 webserver 也要好好设计才行。50K 的 IOPS 写操作对于单个 server 也不是个随随便便就能搞起来的。但好在这简单的 server 你可以横向拆分，根据请求来源的设备做个路由，分到几个实例里就行了，非常容易。