本文目录一览：
- 1、怎么查看redis数据缓存的日志
- 2、Filebeat:使用Filebeat收集日志
- 3、架构设计:文件服务存储设计
- 4、Redis(四)-日志
2、支持定期导出内存的Snapshot 与 记录写操作日志的Append Only File两种模式 。Replication：Master-Slave模式，Master可连接多个只读Slave，暂无专门的Geographic Replication支持 。
3、使用 `get key` 命令来查看指定键的值 。
4、首先找到redis的安装目录 ， 如下图测试环境目录 ， 进入到/opt/install/redis-19/src ， 如下图所示 。需要注意，一般情况下是在redis的安装目录下，有时也会在bin目录下，如下图所示 。
5、在 Redis 中查看数据可以使用以下命令：keys pattern 命令可以列出匹配给定模式的所有键名 。例如，执行 keys * 可以列出所有的键名 。type key 命令可以查看指定键的数据类型 。
Filebeat:使用Filebeat收集日志1、Filebeat是一个日志文件托运工具，做为一个agent安装到服务器上，filebeat会监控日志目录或者指定的日志文件，追踪读取这些文件（追踪文件的变化，不停的读） ， 并且转发这些信息到elasticsearch或者logstarsh中存放 。
2、Filebeat模块很好的入门，它是轻量级单用途的日志收集工具，用于在没有安装java的服务器上专门收集日志，可以将日志转发到logstash、elasticsearch或redis等场景中进行下一步处理 。
3、那么配置文件的路径就应该是~/filebeat-4-linux-x86_64/filebeat.yml） 。由于我的预期目标是将filebeat收集的日志发送到kafka ， 所以配置output就选择了kafka 。读者可根据自己的使用场景，配置output 。
架构设计:文件服务存储设计【redis怎么存大量的日志数据 redis日志收集】前面的架构没有对存储进行特别设计，直接使用了本地存储 。考虑到后期文件数量可能会越来越多 ， 本地存储可能无法支撑，且本地存储的安全性也没有保障 。为了便于后期扩展，需要对「存储」部分进行设计 。
分层结构：基于分层的文件级结构是将代码划分为不同功能的层，例如用户界面层、业务逻辑层和数据访问层等 。每一层都有自己独立的代码和文件，便于更好地管理和维护代码 。
转换服务根据配置委托对应的工具类来进行相应的操作（代码略）：提供两个接口：本文给出了一个文件服务相对完整的架构设计与实现过程 。整个架构设计流程如下：整个过程对各个约束做出了对应的决策，并进行了验证 。
数据架构设计：数据架构设计是指建立数据资产的逻辑结构和组织方式，包括数据的分类、组织、关系和层次等方面的设计 。
Redis(四)-日志从上面的例子中，可以看出每一条慢查询日志都有4个属性组成：可以使用 slowlog len 命令获取慢查询日志的长度，比如：在上例中 ， 当前Redis中有121条慢查询日志 。
Libevent为了迎合通用性造成代码庞大（目前Redis代码还不到libevent的1/3）及牺牲了在特定平台的不少性能 。Redis用libevent中两个文件修改实现了自己的epolleventloop（4） 。
如图5-4所示，表示Redis持久化文件加载流程 。
