简单的操作的话完全没必要保存到硬盘，但是他这个历史资料可查，多个网站管理，后台还是少不了数据库的
antirez 设计 Redis 时的核心考量 ------把高频的实时操作放在内存扛性能，把需要持久化的历史资料、多网站管理数据放回数据库做存储 ，本质是「内存 + 磁盘」的分层存储思路，刚好契合LLOOGG.com的业务场景。
LLOOGG.com的核心痛点本就是实时的访客记录推入 / 弹出 ：每个网站的最新 10000 条记录需要高频读写、先进先出，这部分放 MySQL 会被硬盘 I/O 拖垮，所以 Redis 原型用纯内存做这个环节，O (1) 的操作速度直接解决高并发；但多网站的基础配置、非实时的历史统计数据、长期的访问归档这些内容，本身读写频率低、需要持久化和复杂的查询管理，完全没必要占宝贵的内存，交给 MySQL 这类磁盘数据库处理才合理。
甚至 Redis 后来加入持久化功能（RDB/AOF），也不是为了替代数据库做全量存储，只是为了防止内存数据丢失 ------ 比如重启后能恢复最新的实时数据，而真正的历史资料、后台管理的核心数据，依然要落地到传统数据库，这也是现在互联网系统「缓存 + 数据库」架构的雏形。
简单说就是各司其职：Redis 扛高频实时的简单操作，数据库存需要长期保留、复杂管理的历史 / 配置数据，既解决性能问题，又满足后台管理和历史可查的需求。
一、LLOOGG.com解决负载的早期实验原型：接近 PHP+C 本地调用，无 TCP 端口
antirez 最初为解决LLOOGG.com的 MySQL 性能问题，编写的内存数据库原型 是本地级别的 C 语言实现 ，结合LLOOGG.com作为 PHP 开发的 Web 网站的特性，这个原型大概率是以C 扩展（非 DLL，Linux 环境下为 so 库） 的形式供 PHP 调用：
- 运行方式：PHP 作为 Web 开发语言，通过加载 C 语言编写的本地扩展，直接调用内存中的列表操作逻辑，属于进程内 / 本地调用，无需通过 TCP 端口进行网络通信；
- 无独立服务：此时还没有 Redis 的独立服务形态，只是为 PHP 网站定制的本地性能优化组件，自然不存在 TCP 端口监听；
- 核心目的：仅解决 PHP 网站中 "列表推入 / 弹出" 的本地性能问题，避开 MySQL 的硬盘 I/O 瓶颈，无需网络交互能力。
二、正式版 Redis（2009 年诞生）：独立 C 语言服务，核心基于 TCP 端口通信
antirez 在原型验证可行后，用 C 语言重写并增加持久化、网络通信等功能，正式诞生的 Redis 与 "PHP+C DLL、无 TCP 端口" 完全不符，核心特性为：
- 独立的 C 语言服务进程：Redis 是完全脱离 PHP 的独立服务，并非 PHP 的扩展 / DLL，可单独启动、运行，支持跨语言、跨进程调用；
- 默认基于 TCP 端口通信 ：Redis 从 1.0 版本开始就默认监听TCP 6379 端口，通过自定义的 RESP 协议实现客户端与服务端的网络通信，这是 Redis 作为 "远程字典服务" 的核心基础；
- 支持多种通信方式 ：除了 TCP 端口，Redis 还支持 Unix 域套接字（本地通信，无需端口），但这是可选方式，并非默认，而 TCP 端口是其实现分布式、跨机器调用的核心；
- 与 PHP 的关系是 "客户端调用" ：PHP 需通过 Redis 客户端（如 phpredis 扩展）连接 Redis 的 6379 端口，才能操作 Redis 数据，属于网络远程调用，而非本地 C 扩展调用。
补充：关于 "DLL" 的误区
antirez 开发 Redis 的环境是Linux（VPS） ，Linux 系统中 C 语言编写的动态库为so 文件，而非 Windows 下的 DLL 文件；Redis 本身也从未提供过 DLL 版本的核心服务，仅 Windows 下有第三方移植的客户端工具，核心服务仍以 Linux 为主。
总结
表格
| 阶段 | 运行形态 | 与 PHP 的交互方式 | 是否使用 TCP 端口 |
|---|---|---|---|
| LLOOGG.com原型阶段 | PHP 的 C 本地扩展（so 库） | 进程内本地调用 | 否 |
| 正式版 Redis（2009+） | 独立 C 语言服务进程 | 跨进程网络调用 | 是（默认 6379） |
简单来说：最初为 PHP 网站写的优化原型确实是本地 C 扩展、无 TCP 端口 ，但正式版 Redis 是独立的 TCP 网络服务，与 PHP 是客户端 - 服务端的远程调用关系，并非 PHP 的扩展 / DLL。