北京治疗白癜风最好方法 https://jbk.39.net/yiyuanzaixian/bjzkbdfyy/nxbdf/导读：近年来，云原生化、全用户态、软硬协同等技术对KV存储服务产生了巨大的影响，上述技术在极大提升了服务的性能和降低服务成本的同时，也对系统的架构和实现提出了新的要求。百度在信息流和搜索业务中大量使用了KV存储服务，服务每天响应近千亿次各类访问请求，如何运用上述技术提升系统的性能、稳定性和运维人效是我们重点考虑的问题。本文通过介绍我们应用上述技术打造高性能KV存储系统的实践过程，为大家分享了我们在单机性能优化，大规模集群设计、管理等方面的思路和实践经验。全文字，预计阅读时间21分钟。
自年起，百度进入『搜索+信息流』双引擎驱动构建内容生态的“信息分发2.0时代”，搜索、推荐的内容也不再局限于网页，而是引入越来越多的视频、图片、音频等多媒体资源。KV存储作为在搜索和推荐中台中被广泛使用的在线存储服务，更是受到了存储规模和访问流量的双重考验。
至年初，我们投入各类KV存储服务的服务器数量便超过万台，数据规模超过百PB，承接了每天近千亿次的各类访问请求。集群规模的增长除了资源成本的提升，还加剧了运维管理的难度。作为有状态服务，集群的故障机处理、服务器升级、资源扩缩容都需要专人跟进，运维人力随集群规模呈正比增长。彼时又逢推荐业务完成了微服务化改造，业务资源交付和上线都能当天完成，存储资源动辄周级的交付能力也成了业务上线效率的瓶颈。
这些都促使我们对原来的系统架构进行彻底升级，通过提升单机引擎性能和云原生化有效降低资源成本和运维人力成本。同时我们还要满足业务对服务的敏捷性要求，通过云基础设施提供的资源编排能力，使系统具备小时级服务交付能力。
01问题与挑战
1）性能挑战
单机引擎性能是KV系统的关键指标，一般我们通过读写性能（OPS、延时（latency））和空间利用率来衡量引擎的性能，由于当前引擎架构和存储设备硬件性能的制约，我们在引擎中往往只能选择读性能、写性能和空间利用率中某个方向进行重点优化，比如牺牲空间利用率提升写吞吐，或者牺牲写吞吐、提升空间利用率和读吞吐。
这类优化对于业务单一的场景比较有效，之前我们的系统就针对大业务场景进行逐一调参优化，针对其他业务则使用读写性能和空间利用率均衡的『均衡型』引擎接入。
但是百度的信息流和搜索业务规模都非常庞大、业务场景极其复杂，我们接入的数千个业务中有每天更新PB级数据的业务，也有读写比超过:1的业务，还有要求强一致性、存储规模数十PB的业务，不少业务还会体现出潮汐特性，全天流量都集中在某个特定时段。
因此我们通过引擎优化，既要解决如何在降低读写放大的同时，尽可能平衡空间放大的问题；又要在引擎内实现自适应机制，解决业务充分混布场景下，吞吐模式多变的问题。
云原生架构的主要价值在于效率的提升，包括资源利用效率和研发效率两个方面。
2）云原生化挑战
百度信息流和搜索业务对其业务模块制定了统一的云原生化标准：
微服务化：每个服务粒度应该在限定的范围内。容器化封装：一个服务的部署，应该只依赖基础架构以及本容器内的组件，而不应该依赖其他业务服务。动态管理：每个服务应该可以动态调整部署，而不影响自身对外承诺的SLA。
KV服务在对齐上述标准的过程中，主要难点在于容器化改造和动态管理两个方面。
容器化改造方面，单机时代的KV服务以用满整机资源为目标，对内存资源和存储介质IO的使用往往不加任何限制。引擎的容器化改造，要求我们精细化控制对上述资源的使用：
内存资源：存储引擎除了显式使用系统内存，更多的是对pagecache的使用，文件系统中诸如BufferedI/O和文件预读都会产生pagecache。我们需要在引擎中对其加以控制，避免超过容器配额触发硬限。存储介质I/O：KV服务的主要介质是SSD，我们不少业务也需要使用SSD提升读写性能，这些业务本身往往只需要不到GB，因此为了提升SSD的使用率，KV服务需要和这些业务进行混布。这也要求我们不但能有效利用SSDI/O，还要能对I/O加以控制，避免影响混布业务。
动态管理则要求业务具有一定的容错能力和弹性伸缩能力，由于KV是典型的有状态服务，兼具了数据持久化、多分片、多副本等特点，我们在动态管理中需要
