犯了好几个错,都是因为信赖第三方数据。
唉,呐呐呐。
果然不是自己程序,不能够信仰这些东西,任何时候都要切记做好备份策略是什么,以保证服务的可用性。
唉,为SB的自己感到叹息,不是第1次犯这个错误了。

仔细考虑了好久,觉得这手机还能够再用 1 年!
于是就不打算买 keyone 了,简直就是骗情怀嘛

唉,我好菜啊
想得太多,而做的太少,不该不该
今天开始要把握好时间了,希望明年看到这条「嘟嘟」的时候,我能够向目标更进一步

熬夜一时爽,今天一整天都没有干劲 =-=

真实只是以为做个调度的事情,哪有这么复杂;慢慢地了解到,有好多边界情况还未处理,如依赖的服务挂了怎么办?数据不一致怎么办?决策周期太长怎么办?等等问题。
果然当初还是 naive

果然是当初把这个系统看得太简单了,现在再看一遍,完全是不一样的感觉。

「怪怪守护神」好好看啊。
而「黄漫老师」全靠萌

看了2天 folly/atomic_shared_ptr,终于明白它的思想了:
atomic_store(&a, new_a) 时会将 a 的引用计数减 1,按照正常的引用计数方式,如果在实现 atomic_load 时有获得裸指针 ptr,那么 ptr 的有效性是无法保证的。
因此需要避免 atomic_store 引发 a 对象的析构,这也正是 folly 的巧妙之处。假设系统最大并发数为 N,那么如果 atomic_shared_ptr 初始就有 N 的引用计数,atomic_store 析构未被 atomic_load 的部分,即这里隐含着需要记录 atomic_load 的访问次数,然后保证 atomic_load(&a) 内部获得 a 的裸指针必定有效。设同时存在的 atomic_load 并发数为 K,那么在 atomic_store 中减少的引用计数为 (N - K),剩下 K 个。于是将 a 对象的析构工作交给了普通的 shared_ptr。也就避免了前面所说的持有的裸指针失效的情况。

唉,线上机器的 protobuf 版本太低,为了兼容性以及不影响后续的部署,还是决定把 proto 文件中的 map 类型换成了 repeated xxx

啊,又要看 php 的代码了,特别是上了年代的 php 代码,真是折磨

LinuxRocks.Online

Linux Geeks doing what Linux Geeks do..