Review

这篇文章 Timers and time management in the Linux kernel. Part 1. 是出自 linux-insides

这篇文章 Measuring Transactional Integrity in Airbnb’s Distributed Payment Ecosystem

 这篇文章Re-Architecting the Video Gatekeeper 是出自 Netflix Technology Blog。 Netflix上的视频需要通过Title Operations 团队的策划，使其遵守的合同；字幕、配音、翻译能够提供给合适的人群；标题名称和概要可供使用和翻译；满足各个国家的成熟度等级（分级）。 Gatekeeper是Netflix的系统， 他通过汇集多个上游系统数据， 应用一些业务逻辑，为每一个国家地区每一个视频状态的输出来完成器规定任务。GateKeeper 设置这些视频是否对用户可见。为Title Operations 指出缺少的内容， 协助其工作。 现存问题： GateKeeper是一个事件驱动的系统，上游系统每个改变都会向GateKeeper发送事件，GateKeep再通过访问每个上游服务来响应事件。可能会出现下问题： I/O 瓶颈 处理延时 事件丢失 而主动扫描处理一些指定目录可以缓解这些问题， 但是增加了更多的事件。 解决方案： 使用技术：Hollow 可以看下这篇文章使用技术 Hollow ( Drew Koszewnik)，（ 2016年，是这篇的作者） Netflix Hollow是一个java库和工具集，用于将内存数据集从单个生产者传播到许多消费者，以实现高性能的只读访问。 适合小到中级数据集 Hollow 第一阶段： 使用Hollow为每个上游系统在GateKeeper增加缓存， 在指定周期内循环迭代处理所有国家地区的视频，并生成完整输出。 第二阶段： 由于第一个阶段时间片相对较长， 整个数据来自实际数据源，一个迭代周期需要很长时间。需要进一步优化。 将Hollow分为更小时间片单位， 应用程序将每次的更改通过kafka推送 Hollow，辅助周期性的整个数据源扫描来防止数据遗漏。 效果： 性能及可用性提高：消除了I/O瓶颈，提高了性能，单个上游系统故障下可以通过过时数据进行评估。 对于新投产版本，将某一个时间X的数据做为输入， 将其输出结果其与生产版本应用的输出结果进行对比（diffed ）来准确判断是否达到预期效果。对于开发，验证，部署都比之前有了很大提高， 安全性方面也比以前架构更高。 在文末也写道将在未来几个季度实现这一目标。 对于文中描述的实时推送，全量补齐方式，实施的项目中也使用过，不过是联机+批量模式：报文从一个系统A实时推送到系统B， 夜间再通过下发批量进行全量更新补全推送时丢失的信息。 对于数据重放到预发布版本，与生产版本比较执行执行结果， 来验证新版本是否达到预期效果，和我现在项目中验证方式不一样， 目前投产后通过实际交易进行验证， 如果能方便将相关数据重放到新版本进行验证，确实将减少不少验证的工作， 不过也需要相应的应用做出相关的改造才可以。

这篇文章 Scaling Appsec at Netflix 是出自 Netflix Technology Blog Netflix的 应用安全团队的主要服务对象是在云基础架构上发布应用的工程团队， Netflix安全主张：安全是每个产品团队的责任 Netflix安全团队工作主要分为三类： 应用安全运营功能：传统的AppSec活动： BUG赏金分类，测试， 威胁建模，漏洞管理，产品安全。 安全合作伙伴关系：推动整体安全改进降低风险。 应用安全自动化：构建全面的应用程序库并启动自助安全指导。 运营Appsec功能由于存在高度中断，非持续性，过去的几个月，团队进行了重组，分为自动化和合作伙伴小组两个团队。 APPsec自动化队目标是提供 一致，可操作， 自我服务，为开发提供指导。通过Spinnaker 的平台，为开发人员提供单一的视图提供相关操作， 确保应用安全。 安全工作从过去的使用一些传动的DevSecOps方法如：静态代码扫描，动态测试，反模式grep， 转变为使用自动化方式提供自助服务。 合作伙伴小组更关注于与具有高风险的工程和产品团队（例如支付工程）密切合作， 目标是确定安全风险领域， 专注于更大的战略举措从而降低风险。 团队的最终目标是退出运营职责，将工作重点放到自动化和合作伙伴两种工作模式上。

这篇文章CFI directives in assembly file (18 Jan 2017)， 是出自google 工程师Adam Langley 问题提出： 函数调用栈 1 2 3 4 5 6 7 8 : : | caller's stack | +----------------+ <----$rsp value before CALL | return address | +----------------+ <----$rsp at function entry | caller's rbp | +----------------+ <----$rbp always points here | callee's stack | 函数调用中 调用call指令时将call指令的下一条指令 return address 入栈， 其中return address存放在RIP寄存器中也就是将 RIP入栈，之后进入子函数后会将父函数的栈基地址入栈，其中父函数的栈基地保存在RBP寄存器中。 函数栈调用框架： push rbp mov rbp, rsp ...

这篇文章 Delightful User Interfaces: Easter Eggs 是出自 Netflix Technology Blog

这篇文章 Predictive CPU isolation of containers at Netflix 是出自 Netflix Techno

详解 Linux 内核 RCU 的 API 接口和使用方法

RCU 在实际场景中的使用方法和最佳实践

深入理解 Linux 内核 RCU（Read-Copy-Update）机制的基本原理