LRU，最近最少使用（Least Recently Used，LRU），经典缓存算法。
虽然大型语言模型（LLM）的性能表现足够惊艳，但每次接收用户请求时都需要耗费大量显存和计算资源，一旦请求数量超出预期，就极有可能面临ChatGPT刚发布时的宕机、排队、高延迟等窘境。
今年六月，来自加州大学伯克利分校等机构的一个研究团队开源了 vLLM（目前已有 6700 多个 star），其使用了一种新设计的注意力算法 PagedAttention，可让服务提供商轻松、快速且低成本地发布 LLM 服务。
填一下 【BBuf的CUDA笔记】十，Linear Attention的cuda kernel实现解析 留下的坑，阅读本文之前需要先阅读上面这篇文章。这里就不重复介绍背景知识了，只需要知道现在要计算的目标是：
美团第一代的分布式 KV 存储如下图左侧的架构所示，相信很多公司都经历过这个阶段。在客户端内做一致性哈希，在后端部署很多的 Memcached 实例，这样就实现了最基本的 KV 存储分布式设计。但这样的设计存在很明显的问题：比如在宕机摘除节点时，会丢数据，缓存空间不够需要扩容，一致性哈希也会丢失一些数据等等，这样会给业务开发带来的很多困扰。
PaxosStore是微信设计的一套分布式存储系统，并已对核心业务存储做了架构改造。内存云是微信PaxosStore存储体系的组成部分，本文将分享内存云的Paxos改造过程。
发表在 SOSP 2017 上的 KV-Direct 是我的第二篇（第一作者）论文。因为第一篇 SIGCOMM 论文 ClickNP 是谭博手把手带我做的，KV-Direct 也是我自己主导的第一篇论文。
dict字典 字典是一种组合数据，没有顺序的组合数据，数据以键值对形式出现 # 字典的创建 # 创建空字典1 d = {} print(d) # 创建空字典2 d = dict() print(d) # 创建有值的字典， 每一组数据用冒号隔开， 每一对键值对用逗号隔开 d = {"one":1, "two":2, "three":3} print(d) # 用dict创建有内容字典1 d = dict({"one":1, "two":2, "three":3}) print(d) # 用dict创建
线性探测，字面意思就是按照顺序来，从冲突的下标处开始往后探测，到达数组末尾时，从数组开始处探测，直到找到一个空位置存储这个key，当数组都找不到的情况下回扩容（事实上当数组容量快满的时候就会扩容了）；查找某一个key的时候，找到key对应的下标，比较key是否相等，如果相等直接取出来，否则按照顺寻探测直到碰到一个空位置，说明key不存在。如下图：首先存储key=xiaoming在下标0处，当存储key=xiaowang时，hash冲突了，按照线性探测，存储在下标1处，（红色的线是冲突或者下标已经被占用了） 再者key=xiaozhao存储在下标4处，当存储key=xiaoliu是，hash冲突了，按照线性探测，从头开始，存储在下标2处 （黄色的是冲突或者下标已经被占用了）
小区从管控区调整为防范区了，40多天的封闭后终于可以光明正大地下楼遛狗了！许愿能尽快吃上平价麦当劳，而且每顿都有可口可乐！日拱一卒，让我们开始吧！（长文预警哦）
作者：jeryyzhang，腾讯 WXG 后台开发工程师 背景介绍 业务场景 作为以手机为主要平台的移动社交应用，微信内大部分业务生成的数据是有共性可言的:数据键值带有时间戳信息，并且单用户数据随着时间在不断的生成,我们将这类数据称为基于时间序的数据。例如朋友圈的发表，支付账单流水，公众号文章阅读记录等。这类基于时间序的数据通常不会删除，而是会随着时间流逝不断积累，相应需要的存储空间也与日俱增：key 量在万亿级别，数据量达到 PB 级别，每天新增 key 十亿级别。同时在十亿用户的加持下，每天的访问
KV 存储作为美团一项重要的在线存储服务，承载了在线服务每天万亿级的请求量，并且保持着 99.995% 的服务可用性。在 DataFunSummit 2023 数据基础架构峰会上，我们分享了《美团大规模 KV 存储挑战与架构实践》，本文为演讲内容的整理。文章主要分为四个部分：第一部分介绍了美团 KV 存储发展历程；第二部分分享了内存 KV Squirrel 挑战和架构实践；第三部分阐述了持久化 KV Cellar 挑战和架构实践；最后一部分介绍了未来的发展规划。希望这些内容能对大家有所帮助或启发。
在C++98中，STL提供了底层为红黑树结构的一系列关联式容器，在查询时效率可达到
在前面的学习中我们知道了闭散列的运算规则，当两个数据计算得到的位置发生冲突时，它会自动的往后寻找没有发生冲突的位置，比如说当前数据的内容如下：
本文作者腾讯WXG后台开发工程师jeryyzhang，收录时有改动，感谢原作者的分享。
TiDB-Lightning Toolset 是一套快速全量导入 SQL dump 文件到 TiDB 集群的工具集，自 2.1.0 版本起随 TiDB 发布，速度可达到传统执行 SQL 导入方式的至少 3 倍、大约每小时 100 GB，适合在上线前用作迁移现有的大型数据库到全新的 TiDB 集群。
理想的搜索方法：可以不经过任何比较，一次直接从表中得到要搜索的元素。 如果构造一种存储结构，通过某种函数(hashFunc)使元素的存储位置与它的关键码之间能够建立 一一映射的关系，那么在查找时通过该函数可以很快找到该元素。 当向该结构中： 插入元素 根据待插入元素的关键码，以此函数计算出该元素的存储位置并按此位置进行存放 搜索元素 对元素的关键码进行同样的计算，把求得的函数值当做元素的存储位置，在结构中按此位置 取元素比较，若关键码相等，则搜索成功 该方式即为哈希(散列)方法，哈希方法中使用的转换函数称为哈希(散列)函数，构造出来的结构称 为哈希表(Hash Table)(或者称散列表)
在过去的一年里，我一直是负责Wix的事件驱动消息基础设施（基于Kafka之上）的数据流团队的一员。该基础设施被 1400 多个微服务使用。 在此期间，我已经实现或目睹了事件驱动消息传递设计的几个关键模式的实现，这些模式有助于创建一个健壮的分布式系统，可以轻松处理不断增长的流量和存储需求。
去年六月份加入到现在的公司，目前已经一年多了，今年全年的时间，逐步深入的参与到数据库内核的一些 feature 开发中来，做了非常多的事情，包括：
EasyFlash 是我个人开发的第二款开源软件，自 2015 年初正式开源出来，至今（2019.02）已经经历了 4 年多时间。期间有很多其他行业的嵌入式开发者与我取得联系，得知他们已经将 EasyFlash 应用于自己的产品上，我心里也倍感欣慰，可见 EasyFlash 的成熟性已经得到了很多行业的认可。
对于这一问题，很多人都难以给出确切的回答，不知该如何计算 GPU 内存。因为查看 GPU 可以处理哪些 LLM 并不像查看模型大小那么容易，在推理期间（KV 缓存）模型会占用大量内存，例如，llama-2-7b 的序列长度为 1000，需要 1GB 的额外内存。不仅如此，模型在训练期间，KV 缓存、激活和量化都会占用大量内存。
本文主要讨论一个问题：ValueState 中存 Map 与 MapState 有什么区别？
这张图片表达的侧面意思是：红黑树非常难！！！但如果认真阅读了这篇的博客，并且你有 AVL 树的基础的话 (重点是 AVL 树的旋转)，其实你会发现，红黑树难只是指红黑树比较抽象，但它的逻辑其实是比 AVL 树要简单的，并且红黑树的代码也不难写。
对于Android客户端而言，最常见的莫过于SDK提供的SharePreferences(以下简称**SP**)，但其低效率和ANR问题饱受诟病。
Redis本身内容繁杂，要是上来就研究一细节点，如连接池、数据结构，虽可直接学到某个点的详尽源码内容，甚至尽快解决一些事故，但容易溺死在细节汪洋，无法整体把控Redis。
1. 在C++98中，STL提供了底层为红黑树结构的一系列关联式容器，在查询时效率可达到
1. 虽然二叉搜索树的搜索效率很高，当搜索树接近满二叉树时，搜索效率可以达到logN，但是如果数据是有序的，则二叉搜索树会退化为单支树，搜索效率和普通的序列式容器相同了就，所以在搜索树的基础上，两位俄罗斯数学家研究出了平衡搜索树。
这次的挑战者来自大名鼎鼎的谷歌DeepMind，并且一口气推出了两种新架构，——Hawk和Griffin。
当我们进行微批处理(mini-batch)时，虽然能减少计算浪费并以更灵活的方式批处理请求，但由于GPU内存容量的限制（特别是存储 KV 缓存的空间），仍然限制了可以一起批处理的请求数量，这意味着服务系统的吞吐量受到内存的限制。具体的内存管理挑战有如下三个方面:
40节介绍了HashMap，我们提到，HashMap有一个重要局限，键值对之间没有特定的顺序，我们还提到，Map接口有另一个重要的实现类TreeMap，在TreeMap中，键值对之间按键有序，TreeMap的实现基础是排序二叉树，上节我们介绍了排序二叉树的基本概念和算法，本节我们来详细讨论TreeMap。 除了Map接口，因为有序，TreeMap还实现了更多接口和方法，下面，我们先来看TreeMap的用法，然后探讨其内部实现。 基本用法 构造方法 TreeMap有两个基本构造方法： public Tre
rust 是一门非常优秀的语言，我虽然没有特别正式介绍过 rust 本身，但其实已经写了好多篇跟 rust 相关的文章：
作者 | Natan Silnitsky 来源 | Wix 工程博客 最近经常听到谁谁谁用事件驱动了，正好看到一篇不错的关于事件架构的文章，分享给你，希望对你有帮助，以下是正文。 在过去一年里，我一直是数据流团队的一员，负责Wix事件驱动的消息传递基础设施（基于 Kafka）。有超过 1400 个微服务使用这个基础设施。在此期间，我实现或目睹了事件驱动消息传递设计的几个关键模式，这些模式有助于创建一个健壮的分布式系统，该系统可以轻松地处理不断增长的流量和存储需求。 1.消费与投影 针对那些使用非常广泛、已
琳琅满目的乐高积木，通过一块又一块的叠加，可以创造出各种栩栩如生的人物、景观等，不同的乐高作品相互组合，又能为爱好者带来新的创意。
腾讯微信团队于2018年9月底宣布开源 MMKV ，这是基于 mmap 内存映射的 key-value 组件，底层序列化/反序列化使用 protobuf 实现，主打高性能和稳定性。近期也已移植到 Android 平台，一并对外开源。
自建 Redis 系统是得物 DBA 团队自研高性能分布式 KV 缓存系统，目前管理的 ECS 内存总容量超过数十TB，数百多个 Redis 缓存集群实例，数万多个 Redis 数据节点，其中内存规格超过 1T 的大容量集群多个。
我们使用go run运行后，会在控制台终端看到Hello, 世界的输出。我们来看下这段代码：
作者 | Natan Silnitsky 译者 | 平川 策划 | 万佳 在过去一年里，我一直是数据流团队的一员，负责 Wix 事件驱动的消息传递基础设施（基于 Kafka）。有超过 1400 个微服务使用这个基础设施。在此期间，我实现或目睹了事件驱动消息传递设计的几个关键模式，这些模式有助于创建一个健壮的分布式系统，该系统可以轻松地处理不断增长的流量和存储需求。 1消费与投影 针对那些使用非常广泛、已经成为瓶颈的服务 当有遗留服务存储着大型域对象的数据，这些数据使用又非常广泛，使得该遗留服务成为瓶颈时，此
在 2019 年 QCon 全球软件开发大会（上海站）上，美团高级技术专家齐泽斌分享了《美团点评万亿级 KV 存储架构与实践》，本文系演讲内容的整理，第一部分讲述了美团 KV 存储的发展历程；第二部分阐述了内存 KV Squirrel 架构和实践；第三部分介绍了持久化 KV Cellar 架构和实践；最后分享了未来的发展规划和业界新趋势。
关于元组的函数 以下看代码 以下函数，对list基本适用 # len：获取元组的长度 t = (1,2,3,4,5) len(t) 5 # max，min：最大最小值 print(max(t)) print(min(t)) 5 1 # tuple：转化或创建元组 l = (1,2,3,4,5) t = tuple(l) print(t) t = tuple() print(t) (1, 2, 3, 4, 5) () 元组的函数 基本跟list通用 # count：计算指定数据出现的次数 t = (2,1,
分布式系统利用卸载来减少 CPU 负载变得越来越流行。远程直接内存访问 (RDMA) 卸载尤其变得流行。然而，RDMA 仍然需要 CPU 干预来处理超出简单远程内存访问范围的复杂卸载。因此，卸载潜力是有限的，基于 RDMA 的系统通常必须解决这些限制。 我们提出了 RedN，这是一种原则性的、实用的方法，可以实现复杂的 RDMA 卸载，无需任何硬件修改。使用自修改 RDMA 链，我们将现有的 RDMA 动词接口提升为图灵完备的编程抽象集。我们探索使用商用 RDMA NIC 在卸载复杂性和性能方面的可能性。我们展示了如何将这些 RDMA 链集成到应用程序中，例如 Memcached 键值存储，从而使我们能够卸载复杂的任务，例如键查找。与使用单侧 RDMA 原语（例如 FaRM-KV）的最先进的 KV 设计以及传统的 RPC-over-RDMA 方法相比，RedN 可以将键值获取操作的延迟减少高达 2.6 倍。此外，与这些基准相比，RedN 提供性能隔离，并且在存在争用的情况下，可以将延迟减少高达 35 倍，同时为应用程序提供针对操作系统和进程崩溃的故障恢复能力。
1：HBase官网网址：http://hbase.apache.org/ 2：HBase表结构：建表时，不需要指定表中的字段，只需要指定若干个列族，插入数据时，列族中可以存储任意多个列（即KEY-VA
哈希查找表一般会存在“碰撞”的问题，就是说不同的 key 被哈希到了同一个 bucket。一般有两种应对方法：链表法和开放地址法。链表法将一个 bucket 实现成一个链表，落在同一个 bucket 中的 key 都会插入这个链表。开放地址法则是碰撞发生后，通过一定的规律，在数组的后面挑选“空位”，用来放置新的 key。
etcd 是一个高可用强一致性的键值仓库在很多分布式系统架构中得到了广泛的应用，本教程结合一些简单的例子介绍golang版本的 etcd/clientv3中提供的主要功能及其使用方法。
安全业务的核心逻辑在安全策略中实现。整个的策略开发流程包括特征数据的收集，安全策略的编写实现，和策略的反馈评估。其中特征数据的收集是必不可少的环节，数据的质量将直接影响安全策略的效果。
首先来梳理一下业务开发过程中经常面临的本地缓存的一些需求。我们一般做缓存就是为了能提高系统的读写性能，缓存的命中率越高，也就意味着缓存的效果越好。其次本地缓存一般都受限于本地内存的大小，所有全量的数据一般存不下。那基于这样的场景一方面是想缓存的数据越多，则命中率理论上也会随着缓存数据的增多而提高；另外一方面是想，既然所有的数据存不下那就想办法利用有限的内存存储有限的数据。这些有限的数据需要是经常访问的，同时有一定时效性(不会频繁改变)的。基于这两个点展开，我们一般对本地缓存会要求其满 足支持过期时间、支持淘汰策略。最后再使用自动管理内存的语言例如golang等开发时，还需要考虑在加入本地缓存后引发的GC问题。
微信作为月活过10亿的国民级应用，其安全能力备受关注。值得注意的是，没有足够的特征数据，安全策略将是"无根之木，无源之水"。微信安全数据仓库作为安全业务的特征数据存储中心，每天服务了万亿级的特征数据读写请求，为整个微信安全策略提供了可靠的数据支撑，是微信安全的一块基石。事实上，微信安全数据仓库不仅仅是一个存储中心，更是一个特征管理和数据质量管理的中心。本文将介绍安全数据仓库的起源、演进、当前的架构设计和数据质量保证系统的实现，请往下阅读。
领取专属 10元无门槛券
手把手带您无忧上云
