(19)国家知识产权局 (12)发明 专利申请 (10)申请公布号 (43)申请公布日 (21)申请 号 202210872986.6 (22)申请日 2022.07.22 (71)申请人 北京亿中邮信息技 术有限公司 地址 100023 北京市朝阳区惠河南 街1132 号通惠大厦C20 3 (72)发明人 佟路林　 (74)专利代理 机构 北京世誉鑫诚专利代理有限 公司 11368 专利代理师 刘秀珍 (51)Int.Cl. G06F 8/20(2018.01) G06F 16/22(2019.01) G06F 16/25(2019.01) G06Q 10/10(2012.01) H04L 51/42(2022.01) (54)发明名称 一种基于KV系统的多用户电子邮箱 邮件索 引方法 (57)摘要 本发明提供的一种基于KV系统的多用户电 子邮箱邮件索引方法包括： 构建Server程序架 构； 根据所述Server程序架构构建基于 KV系统的 Key‑List邮箱结构； 构建基于内存的Map结构线 程锁桶； 采用ProtoBuf结构 存储邮件的多个字段 信息。 新增邮件信息字段灵活、 高效， 有效实现了 邮件信息数据字段结构 的向后/向前兼容， 实现 了用户邮箱文 件夹汇总信息和邮件信息的索引。 权利要求书1页 说明书5页 附图1页 CN 115291838 A 2022.11.04 CN 115291838 A 1.一种基于KV系统的多用户电子邮箱邮件索引方法， 其特 征在于， 所述索引方法包括： 构建Server程序架构； 根据所述Server程序架构 构建基于KV系统的K ey‑List邮箱结构； 构建基于内存的Map结构线程锁桶； 采用ProtoBuf结构存 储邮件的多个字段信息 。 2.根据权利要求1所述的一种基于KV系统的多用户电子邮箱邮件索引方法， 其特征在 于， 所述构建Server程序架构具体包括： Server程序为一个多线程的服务程序， 包括网络IO线程池， 用于提供HTTP协议的 Restful接口访问服 务； 工作线程池， 用于进行 KV存储系统的数据查询和更新 服务； 所述网络IO线程池和所述工作线程池之间通过消息队列进行交 互。 3.根据权利要求2所述的一种基于KV系统的多用户电子邮箱邮件索引方法， 其特征在 于， 所述根据所述Server程序架构 构建基于KV系统的K ey‑List邮箱结构具体包括： 工作线程池线程利用基于KV存储系统的多条Key ‑Value数据， 构建Key ‑List的邮件夹 信息和邮件信息列表结构， 一条所述Key ‑Value数据为邮件夹信息数据， 多条所述Key ‑ Value数据为邮件信息数据， 每一条所述Key ‑Value数据代表一封邮件数据， 存储邮件的相 关信息； 对所述Key ‑Value数据中 的Key进行内容格式 的规划， Key包括TAG标识字段， 表明Key的 类型， 邮件夹ID和邮件ID字段； 前缀部分包括相同的用户ID； Value包括多个字段， 邮件夹信息的Value包括邮件夹更新时间戳、 邮件夹内邮件数量、 邮件夹内邮件总Size、 邮件夹内最大邮件ID和最小邮件ID， 邮件信息的Valu e包括邮件的时 间戳、 邮件的Size和邮件的摘要信息ProtoBuf序列化数据。 4.根据权利要求1所述的一种基于KV系统的多用户电子邮箱邮件索引方法， 其特征在 于， 所述构建基于内存的Map结构线程锁桶具体包括： 工作线程池的线程在更新用户的邮件夹信 息和邮件信 息时， 为了保证数据的原子性操 作， 使用用户级的线程互斥 锁； 使用了基于内存的Map结构线程锁桶； 在更新KV数据时， 采用了KV系统批量操作接口。 5.根据权利要求1所述的一种基于KV系统的多用户电子邮箱邮件索引方法， 其特征在 于， 所述采用ProtoBuf结构存 储邮件的多个字段信息具体包括： ProtoBuf结构存储邮件信息的多个字段， 在存储到KV系统的Key ‑Value时， 将整个结构 序列化为一个字符串， 读取的时候， 再将此字符串反序列化， 整个过程对用户透明； 如果需要新增邮件信息字段时， 只 需要增加一个ProtoBuf结构的字段， 在对旧数据反 序列化过程中新增的字段会自动采用默认值， 更新时， 会自动将新增的字段序列化到字符 串中， 整个过程对整体数据无任何影响， 数据转换灵活、 高效， 实现了数据结构的向后/向前 兼容。权　利　要　求　书 1/1 页 2 CN 115291838 A 2一种基于KV系统的多用户电子邮箱邮件索引方 法 技术领域 [0001]本发明涉及电子邮件服务器领域， 尤其涉及一种基于KV系统的多用户电子邮箱邮 件索引方法。 背景技术 [0002]电子邮件服务器的其中一个重要功能就是存储多个用户的邮箱信息和邮件原文， 用户通过MUA(如webmail、 pop、 imap)客户端访问电子邮件服务器， 读取个人邮箱的汇总信 息和邮件原文内容。 随着用户数量及其邮件数量的剧增， 电子邮件服务器在显示个人邮箱 汇总信息(文件夹信息、 邮件 数量)和读取邮件原文列 表的时候， 速度越来越慢， 性能也越来 越低， 甚至在大并发、 高负载的情况， 造成电子邮件服 务器宕机或无法服 务。 [0003]基于以上原因， 需要对用户的邮箱汇总信息和邮件原文列表信息进行缓存或是索 引， 以加速用户通过MUA 客户端收取邮件时， 快速显示出用户的 邮箱汇总信息和邮件列 表信 息， 同时也需要提高用户遍历邮件列 表的速度， 以及用户邮箱内邮件 数量发生变更时(比如 新收到邮件、 删除邮件、 将邮件从一个邮件夹移动到另一个邮件夹等)可以快速更新用户的 邮箱汇总信息及调整邮件列表信息 。 [0004]通常的电子邮件服务器的邮箱格式为mbox、 m aildir格式， 分别为采用单一文件或 是目录结构文件的方式组织邮件原文的存储， 而没有相关的邮箱汇总信息的缓存或是索 引， 当需要显示邮箱汇总信息的时候， mbox格式需要对单一文件内的所有邮件原文信息和 数量进行汇总统计， maildir格式需要统计整个目录内的文件数量及 文件大小等信息， 变更 或是移动时， 也都 非常复杂， 所以效率 通常都比较低。 [0005]大部分改进型的电子邮件服务器的邮箱格式依然采用maildir格式或是云存储的 方式存储邮件原文， 但同时会增加 一个索引装置， 存储邮箱的汇总信息和邮件原文列表信 息， 以加快在读取相关信息时的速度。 [0006]其中一种索引装置是以二进制结构化索引文件存储用户的邮件原文信息的方式， 使用结构化文件中的每一个固定大小的结构块记录邮件原文的相关信息(发件人、 收件人、 主题、 大小、 文件ID等等)， 读取信息时， 通过计算结构化文件中结构块的数量及 遍历结构块 信息， 计算出相关的汇总信息， 显示邮件列表信息时， 则可以直接通过读取结构化文件中的 结构块信息， 以达到提升速度的效果。 由于结构化块的数据结构是固定的， 如果需要增加邮 件信息字段， 则需要对整个结构化文件进 行更改， 无论采用在线 方式或是离线方式， 都需要 非常大的工作量。 [0007]另外一种索引装置是以MySQL数据库表存储用户的邮件原文信息的方式， 使用数 据库的邮件夹信息表和邮件信息表， 将所有用户的邮件夹信息(邮件夹名、 邮件数量等等) 和邮件原文的相关信息(发件 人、 收件人、 主题、 大小、 邮件夹ID、 文件ID等等)按表字段的方 式存在数据库的记录中， 读取信息时， 通过SQL相关语句进 行查询、 遍历， 在 进行邮件新增或 删除等数据变更时， 由于邮件夹信息表和邮件信息表存在关联更新关系， 为了保证原子更 新， 就需要使用数据库事务操作， 数据库事务操作的性能相对较低。 同时 随着用户邮件数据说　明　书 1/5 页 3 CN 115291838 A 3