change buffer（在 MySQL 5.6 之前叫 insert buffer，简称 ibuf ）是 InnoDB 5.5 引入的一种优化策略，若二级索引页不在 buffer pool 中，则将针对二级索引页的操作暂时缓存起来，等到该页从磁盘读到 buffer pool 中时再批量的（batch）apply 这些操作，从而达到减少磁盘 I/O 的目的。具体一点就是： 事务 1 执行写操作（e.g update），但针对的二级索引页 P1 并不在 buffer pool 中 于是 client 1 将这个操作缓存到 change buffer 里，即添加一个 entry（ibuf insert） 事务 2 需要读操作，将 P1 读到 buffer pool 中 将 change buffer 里相关的缓存的操作全部合并（merge）至 P1（ibuf merge） 将 P1 返回给用户线程
2021年下半年以来，在新冠疫情和互联网政策的冲击之下，各大互联网公司都在进行降本增效。降本增效的一大核心手段就是优化计算资源成本，本文将以腾讯某内部 Kubernetes/TKE 业务为案例，详细阐述如何从 0到1（成本数据采集与分析、优化措施、行业现状与方案选型、方案设计与实现、落地与效果、总结）进行大规模、高可靠、高效率的成本优化的实践，并在这过程中实现了零故障突发，CPU 最高节省70%，Memory 节省50%的成果。本文所介绍的成本优化整体方案实现是腾讯云开源项目 Crane 的内部雏形版，我们在内部成功实践的基础上，将相关设计方案与最佳实践进一步输出给对外开源项目 Crane（https://github.com/gocrane/crane)，致力于为云原生广大用户提供云成本优化一站式解决方案。
要确保Kafka在使用过程中的稳定性，需要从kafka在业务中的使用周期进行依次保障。主要可以分为：事先预防（通过规范的使用、开发，预防问题产生）、运行时监控（保障集群稳定，出问题能及时发现）、故障时解决（有完整的应急预案）这三阶段。
Prometheus 作为云原生时代最流行的监控组件，已然成为社区监控事实上的标准，但是在多集群，大集群等场景下，只使用 Prometheus 是远远不够的；单集群场景下我们一般主要关注指标采集、存储、告警、可视化等基础监控能力，随着集群规模的增大，监控系统的弹性以及可扩展性成为首要解决的痛点问题，为此社区诞生了 Thanos、Cortex、Prometheus 联邦等一系列成熟的解决方案，我们也通过自研的 Kvass 解决方案，通过将服务发现与采集过程分离，以及自研的任务分片算法，无侵入式的支持采集任务横向扩展，满足大规模集群场景下的采集和监控需求。在分布式云场景下，用户集群往往采用混合多云多集群的部署架构，集群的地理位置更加分散，网络环境更加复杂，为此我们也在寻找一种新的方案来统一解决此类问题。本文以腾讯云跨账号集群统一监控为例，介绍分布式云下的多集群监控方案的最佳实践。
在《Effective HPA：预测未来的弹性伸缩产品》 一文中，我们提到原生HPA并不完美。基于阈值被动响应机制的滞后性与众多应用冷启动慢等原因导致很大一部分应用无法安心配置弹性。 基于DSP（Digital Signal Processing，数字信号处理）算法的预测机制，Crane确保在阈值到达之前就能提前感知并使应用提前弹出，确保冷启动慢的应用也能有效利用弹性。 在技术交流群中，不断有人问，DSP算法的原理和细节是什么。其所依赖的傅里叶变换号称上个世纪最强算法甚至有史以来最强算法，涉及很多数学基础，巧妙又复杂，学习门槛很高。 因此有必要写一篇文章，将对该算法的细节，以及Crane如何应用该算法公开来。为方便阅读，本文会尽量减少劝退的数学公式的出现次数。
