定时更新配置的C++实现
最近的几个系统都用到了定时更新配置
获取到的配置是需要高频使用的,不能直接使用字符串
需要预处理为整数或浮点数,甚至是一个整数数组
因此整理了一下Config设计:
分为元数据Meta,配置的存储和注册Config两个模块
最近的几个系统都用到了定时更新配置
获取到的配置是需要高频使用的,不能直接使用字符串
需要预处理为整数或浮点数,甚至是一个整数数组
因此整理了一下Config设计:
分为元数据Meta,配置的存储和注册Config两个模块
在维护网络库时,总能遇到一些没太大用处,但是很有意思的小知识,细细碎碎又不成体系,记录一下
2015.5.22整理:
epoll下LT和ET的处理都是大致相同的
LT模式
读buff有数据 / 写buff有空间,就触发
ET模式
读buff有数据,且数据减少或调用epoll_mod时 / 写 buff 空间增加或调用epoll_mod时,才触发
LT模式例子:
https://www.cnblogs.com/lojunren/p/3856290.html
https://github.com/hurley25/ANet
https://juejin.im/post/5ab3c5acf265da2380598efa
https://www.zhihu.com/question/22840801
https://blog.codingnow.com/2012/04/mread.html
在ET模式中,需要主动把数据读完或者写满:
读处理是一直read
返回-1,检查errno,如果是EAGAIN那么不再读(缓冲区读完),如果是其他那么说明连接出错,进行报错然后也不再读。
返回0,说明对端关闭
返回大于0,成功读到数据
写处理是一直write,直到数据写完
返回-1,检查errno,如果是EAGAIN那么不再写(缓冲区写完),如果是其他那么说明连接出错,进行报错然后也不再写。
返回大于0,成功写数据
在使用tcp时,内核的tcp上存在读写缓冲区,上层app通过这个缓冲区来和实际的网络进行通信
app <=> 内核tcp <=> network
本文主要讲述了Borg论文中引用的基于机会成本的E-PVM算法
这个算法的缺点(大型任务难以调度)是在我的场景下是可接受的
对Borg来说,任务实际是一个任务组,亲和需求的任务组需要特别多的资源
而在我的调度问题中,大型任务是很少的,因为我的调度器不提供任务组的概念,由业务来解耦任务组
我尝试理解该算法后做一些优化,然后通过模拟器模拟和分集群测试来查看是否可以提升资源利用率
《Bistro: Scheduling Data-Parallel Jobs Against Live Production Systems》
facebook2015年论文,用于解决离在线混部时,约束离线任务运行在指定资源范围的问题
提出了一种基于树模型的资源调度问题
例如叶子节点是数据库卷,上面的父节点是主机,机架等等
在任务退出时,对影响到的叶子节点以及父节点(直到根节点)进行调度,来避免全部资源池的调度太过耗费性能
Bistro在架构上允许对树的独立资源的根节点,哈希或者按位置进行分区,从而进行并行调度和分布式调度
最近大概间隔1个月,我在使用定时任务类时遇到了两次析构过程中的 bug
这两个 bug 出现在我用别人写的定时任务类时,这两个bug的区别是一个是组合使用的,另一个是继承使用的
由于coredump的堆栈都不在正常的位置,因此这两个bug都花费了我平均一整天的大量时间去定位
另外有个基于协程的定时任务类,这个类不仅只是使用,甚至都是我实现的,尽管 bug 还未发生,我仔细看了下居然也存在类似的问题
因此,我觉得我有必要总结这个问题,避免再次在相同的问题上耗费太多时间,毕竟多线程(协程)问题的定位非常困难
上一篇对glibc和futex进行了源码分析,是我对具体实现的梳理,没有总结性的内容,可以略过不看直接看这一篇总结
本篇总结尝试深入一些,继续挖掘锁这个概念
分析内核在实现锁的过程中是如何解决无效唤醒问题的
为了解决无效唤醒问题,纯用户态的互斥锁性能不够好;纯内核态又在非竞争的条件时需要陷入内核,从而诞生了futex
我对内存屏障以及C++11引入的memory order一直处于一知半解的状态
知道有这么个东西,知道一部分原理,不知道什么场合去用它,一直以来我的多线程工具库里面只有锁,条件变量和原子变量三板斧,错过了很多更细粒度的优化机会。
在ChatGPT的帮助下,终于从头到尾理解了它的底层原理和应用场景
本文属于拾人牙慧的总结,将看到的一些资料整理出来,本文的大纲如下:
缓存一致性
从cpu缓存开始,引出多核cpu的缓存一致性(Cache Coherence)问题
为了解决这个问题,发明了MESI协议,但是这个协议性能还不够好,因此引入了Store Buffer和Invalidate Queue来提高性能
内存一致性
Store Buffer,Invalidate Queue再加上编译器指令乱序和cpu指令乱序,导致了内存一致性(Memory Consistency)无法得到满足
使用各种内存屏障来解决这些问题
C++的memory order
为了简化和细化内存屏障,C++11引入了memory order