“一个字等于多少个字节?”是一个不严谨的问法

“一个字等于多少个字节?”是一个不严谨的问法

直接回答一个字等于多少个字节,也是不严谨的答法。

相关概念:

1、位(bit) 来自英文bit,音译为“比特”,表示二进制位。位是计算机内部数据储存的最小单位

2、字节(byte) 字节来自英文Byte,音译为“拜特”,习惯上用大写的“B”表示。 字节是计算机中数据处理的基本单位。

3、字 (word)计算机进行数据处理时,一次存取、加工和传送的数据长度称为字。一个字通常由一个或多个(一般是字节的整数位)字节构成。

字、字节、位之间的关系

网上看了很多回答,都是很片面的,也就是在有的情况下是对的,有的情况下是错的。

比如这篇文章,看的人很多,点赞的也很多,但指出有错误的却很少。

以下是该文章截图:

以下是评论截图:

论据:

先看一段摘抄自《Computer system: a programmer's perspective》的说明:

Buses are typically designed to transfer fixed-sized chunks of bytes known aswords. The
number of bytes in a word (the word size) is a fundamental system parameter that
varies across systems. Most machines today have word sizes of either 4 bytes (32
bits)or8bytes(64bits).

翻译过来就是说:总线一般被设计来传输固定大小的一块数据,这块数据被称为字(word),一个字包含的字节数(即字的大小)是各种计算机系统里面的基本参数,而且这个参数在不同的系统里通常是不同的。大多数的现代计算机系统里面,一个字要么是4个字节(32位),要么是8个字节(64位).

结论:

       一个字等于多少个字节,与系统硬件(总线、cpu命令字位数等)有关,不应该毫无前提地说一个字等于多少位。

正确的说法:

①:1字节(byte) = 8位(bit)

②:在16位的系统中(比如8086微机) 1字 (word)= 2字节(byte)= 16(bit)

       在32位的系统中(比如win32) 1字(word)= 4字节(byte)=32(bit)

       在64位的系统中(比如win64)1字(word)= 8字节(byte)=64(bit)

内推:

有想换工作的小伙伴吗?

对网易感兴趣的话欢迎添加本人微信:urus35

各种方向的岗位都有噢~(坐标:广州北京上海杭州)

<think>好的,用户之前已经询了Redis的常见数据结构及其应用场景,现在他们进一步希望了解每个数据结构的底层实现原理。我需要确保每个结构的解释清晰且详细,同时保持回答的结构化。 首先,回顾之前的回答,用户可能已经对每个数据结构有了基本了解,现在需要深入底层。我需要逐个分析每种数据结构的实现,比如String可能使用SDS,List可能涉及双向链表或压缩列表,Hash可能使用哈希表或ziplist,等等。 接下来,我需要确认每个数据结构的底层结构在同版本中的变化,例如Redis 7.0中List是否仍使用quicklist,或者是否有新的结构引入。同时,要注意到配置参数如ziplist的条目限制,这些会影响内部编码方式。 然后,用户要求每个数据结构单独回复一次消息,但根据当前平台限制,可能需要在一个回答中分点说明。我需要按照之前的列表顺序,逐一详细解释每个数据结构的实现原理,包括数据结构、编码方式、内存优化策略等。 同时,需要保持语言简洁,避免过于技术化的术语,但又要准确。例如,解释SDS时,要提到其优势,如O(1)长度获取和二进制安全。对于ziplist和hashtable的区别,要说明在同数据量下的自动转换。 此外,用户可能对性能优化感兴趣,比如为什么使用跳跃表而是平衡树,或者HyperLogLog如何实现高效基数估算。需要简要提及这些内容,但过于深入算细节。 最后,确保每个部分结构清晰,使用标题和子项,帮助用户快速浏览。检查是否有遗漏的数据结构,如扩展结构中的位图、GEO等,确保覆盖全面。同时,提醒用户底层实现可能因版本而异,建议参考官方文档,显示回答的严谨性。</think>好的,我逐个介绍 Redis 数据结构的底层实现原理: --- ### 一、符串(String) **底层结构**:`SDS` (Simple Dynamic String) - **内存布局**: ```c struct sdshdr { int len; // 已用字节长度 int free; // 剩余可用字节 char buf[]; // 实际存储数据的柔性数组 }; ``` - **特点**: 1. 预分配空间策略:扩容时按需分配额外空间(类似C++ vector) 2. 二进制安全:通过 `len` 判断符串结束,而非依赖 `\0` 3. 兼容 C 符串:SDS 末尾仍保留 `\0`,可直接使用 C 符串函数 - **编码类型**: - `int`:存储整数时直接使用 long 类型 - `embstr`:短符串(≤44字节)优化存储 - `raw`:长符串常规存储 --- ### 二、列表(List) **底层结构**:`quicklist` (Redis 3.2+) - **组成**:双向链表 + ziplist 的混合结构 - 每个节点是一个 `ziplist`(压缩列表) - 通过配置 `list-max-ziplist-size` 控制单个 ziplist 的最大容量 - **ziplist 原理**: - 连续内存块,通过偏移量定位元素 - 每个元素存储前驱长度和自身内容 - 插入/删除操作可能引发连锁更新(需重新计算后续元素位置) --- ### 三、哈希(Hash) **底层结构**:`dict` (哈希表) 或 `ziplist` - **默认编码**: - `ziplist`:当所有键值对的键和值的长度都 ≤ `hash-max-ziplist-value`(默认64字节)且键值对数 ≤ `hash-max-ziplist-entries`(默认512) - `hashtable`:满足上述条件时自动转换 - **哈希表实现**: - 使用链地址解决哈希冲突 - 渐进式 rehash:扩容时逐步迁移数据,避免服务阻塞 --- ### 四、集合(Set) **底层结构**:`intset` 或 `hashtable` - **intset 条件**: - 所有元素都是整数 - 元素数量 ≤ `set-max-intset-entries`(默认512) - **intset 细节**: - 有序存储,查找使用二分 - 自动升级:插入新元素时动态调整存储类型(int16 → int32 → int64) - **hashtable 实现**: - 哈希表存储(类似 Hash 结构),但 value 固定为 NULL --- ### 五、有序集合(Sorted Set) **底层结构**:`ziplist` 或 `skiplist + dict` - **ziplist 条件**: - 元素数量 ≤ `zset-max-ziplist-entries`(默认128) - 每个元素的值的长度 ≤ `zset-max-ziplist-value`(默认64字节) - **skiplist + dict 结构**: 1. **跳跃表(skiplist)**: - 多层链表结构,支持 $O(\log n)$ 复杂度的范围查询 - 每个节点存储元素分值(score)和指向后续节点的指针数组 2. **典(dict)**: - 存储 `元素 → 分值` 的映射,实现 $O(1)$ 时间复杂度的单元素查询 --- ### 六、扩展数据结构 1. **位图(Bitmap)** - **底层**:String 的二进制位操作 - 通过 `SETBIT` 和 `GETBIT` 操作特定偏移量(offset)的 bit 位 2. **HyperLogLog** - **底层**:使用 16384 个 6bit 寄存器(共 12KB) - 基于概率算,通过观测数据分布估算基数 3. **地理空间(GEO)** - **底层**:使用 Sorted Set 存储 - 经纬度通过 `geohash` 算转换为 52 位整数作为 score 4. **流(Stream)** - **底层**:`radix tree`(基数树)结构 - 每个消息条目包含唯一 ID(时间戳+序列号)和多组键值对 --- ### 关键设计思想 1. **内存优化**:小数据优先使用连续内存结构(如 ziplist) 2. **性能权衡**:在时间复杂度和空间利用率间寻找平衡 3. **自动转换**:根据数据量动态切换底层编码方式 4. **惰性删除**:删除操作仅标记空间,后续逐步回收 需要具体某个结构的更详细实现分析吗?
评论 41
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值