面试题手册

Puppeteer 如何实现页面截图和 PDF 生成？有哪些高级选项和实际应用场景？

Puppeteer

阅读 0·2月19日 19:38

什么是 Puppeteer？它有哪些主要特性和应用场景？

Puppeteer 是一个 Node.js 库，它提供了一个高级 API 来通过 DevTools 协议控制无头 Chrome 或 Chromium。它还可以配置为使用完整（非无头）Chrome 或 Chromium。核心特性：无头浏览器控制：Puppeteer 可以在无头模式下运行 Chrome，这意味着浏览器界面不会显示，但所有功能仍然可用。页面操作：可以生成页面的屏幕截图和 PDF，抓取 SPA（单页应用）并进行内容爬取。自动化测试：可以模拟用户操作，如点击、输入文本、导航等，非常适合自动化测试。性能分析：可以捕获时间线跟踪，帮助诊断性能问题。网络拦截：可以拦截和修改网络请求，用于测试和调试。基本使用示例：const puppeteer = require('puppeteer');(async () => { // 启动浏览器 const browser = await puppeteer.launch(); // 创建新页面 const page = await browser.newPage(); // 导航到指定 URL await page.goto('https://example.com'); // 截图 await page.screenshot({ path: 'example.png' }); // 关闭浏览器 await browser.close();})();主要应用场景：网页爬虫：抓取动态渲染的网页内容自动化测试：E2E 测试、UI 测试PDF 生成：将网页转换为 PDF 文档性能监控：分析页面加载性能截图服务：批量生成网页截图与 Selenium 的区别：Puppeteer 直接使用 Chrome DevTools 协议，速度更快Selenium 支持多种浏览器，Puppeteer 主要支持 Chrome/ChromiumPuppeteer API 更简洁，学习曲线较低Puppeteer 对现代 Web 技术支持更好

Puppeteer

阅读 0·2月19日 19:38

Puppeteer 的性能优化有哪些策略？如何提高爬虫效率和降低资源消耗？

Puppeteer

阅读 0·2月19日 19:38

Puppeteer 的无头模式和有头模式有什么区别？分别在什么场景下使用？

Puppeteer 的无头模式和有头模式是两种不同的浏览器运行方式，各有其适用场景。无头模式（Headless Mode）：无头模式是 Puppeteer 的默认模式，浏览器在没有图形界面的情况下运行。特点：不显示浏览器窗口，所有操作在后台进行占用系统资源更少，运行速度更快适合服务器环境和自动化任务不需要显示器的支持启用方式：const browser = await puppeteer.launch({ headless: true // 默认值，可以省略});适用场景：CI/CD 管道中的自动化测试服务器端网页爬虫批量截图和 PDF 生成性能测试和监控定时任务和后台处理有头模式（Headful Mode）：有头模式会显示完整的浏览器界面，用户可以看到所有操作过程。特点：显示完整的浏览器窗口可以实时观察浏览器行为便于调试和开发占用更多系统资源启用方式：const browser = await puppeteer.launch({ headless: false});适用场景：开发和调试阶段需要可视化操作的场景演示和教学手动测试辅助复杂交互的调试性能对比：| 指标 | 无头模式 | 有头模式 ||------|---------|---------|| 内存占用 | 较低 | 较高 || 启动速度 | 快 | 慢 || CPU 使用 | 低 | 高 || 调试难度 | 较高 | 较低 || 适用环境 | 服务器 | 开发机 |最佳实践：开发阶段：使用有头模式进行调试测试环境：使用无头模式提高效率生产环境：始终使用无头模式混合使用：根据需要动态切换模式示例代码：const puppeteer = require('puppeteer');// 根据环境变量选择模式const isDev = process.env.NODE_ENV === 'development';const browser = await puppeteer.launch({ headless: !isDev, devtools: isDev // 开发模式下打开 DevTools});

Puppeteer

阅读 0·2月19日 19:38

Puppeteer 如何实现网络请求拦截？有哪些实际应用场景？

Puppeteer

阅读 0·2月19日 19:38

Redis 与 MySQL、MongoDB、Memcached 有什么区别？如何选择？

Redis 与其他数据库（如 MySQL、MongoDB、Memcached）在多个方面存在显著差异，理解这些差异有助于在实际项目中做出正确的技术选型。1. Redis vs MySQL数据存储方式Redis：基于内存存储，数据主要在内存中支持持久化到磁盘（RDB、AOF）适合存储热点数据、缓存数据MySQL：基于磁盘存储，数据主要在磁盘上支持内存表（MEMORY 引擎）适合存储持久化数据、结构化数据数据结构Redis：支持丰富的数据结构：String、Hash、List、Set、ZSet、Bitmap、HyperLogLog、Geo数据结构简单，适合键值对存储不支持复杂的关系查询MySQL：支持关系型数据模型，支持表、索引、外键等支持复杂的 SQL 查询支持事务（ACID）性能特点Redis：读写速度极快，单机可达 10 万+ QPS支持高并发适合读多写少的场景MySQL：读写速度相对较慢，单机几千到几万 QPS支持读写分离、分库分表适合复杂的查询场景适用场景Redis：缓存会话存储计数器排行榜消息队列实时统计MySQL：用户信息订单信息商品信息交易记录复杂查询2. Redis vs MongoDB数据存储方式Redis：基于内存存储支持持久化数据结构简单MongoDB：基于磁盘存储支持内存映射文件文档型数据库数据结构Redis：键值对存储支持多种数据结构不支持复杂查询MongoDB：文档型存储（BSON 格式）支持嵌套文档支持复杂的查询和聚合性能特点Redis：读写速度极快适合简单操作不支持复杂查询MongoDB：读写速度较快支持复杂查询支持索引优化适用场景Redis：缓存实时数据简单的键值对存储MongoDB：文档存储内容管理日志存储大数据存储3. Redis vs Memcached数据存储方式Redis：基于内存存储支持持久化支持数据结构Memcached：基于内存存储不支持持久化只支持简单的键值对数据结构Redis：支持多种数据结构支持复杂操作支持事务Memcached：只支持 String 类型只支持简单的 GET/SET 操作不支持事务性能特点Redis：读写速度极快支持复杂操作支持持久化Memcached：读写速度极快只支持简单操作不支持持久化适用场景Redis：缓存会话存储排行榜计数器消息队列Memcached：简单的缓存对象缓存数据库查询缓存4. 技术选型建议选择 Redis 的场景需要高性能缓存：Redis 的读写速度极快，适合作为缓存层需要丰富的数据结构：Redis 支持多种数据结构，适合复杂的数据操作需要持久化：Redis 支持持久化，数据不会因为重启而丢失需要高可用：Redis 支持主从复制、哨兵模式、集群模式，可以实现高可用需要实时统计：Redis 支持实时统计，如计数器、排行榜等选择 MySQL 的场景需要持久化存储：MySQL 基于磁盘存储，适合持久化数据需要复杂查询：MySQL 支持 SQL 查询，适合复杂的业务逻辑需要事务支持：MySQL 支持 ACID 事务，适合需要事务的场景需要关系型数据：MySQL 支持关系型数据模型，适合关系型数据选择 MongoDB 的场景需要文档存储：MongoDB 是文档型数据库，适合存储文档需要灵活的数据结构：MongoDB 支持灵活的数据结构，适合快速迭代需要大数据存储：MongoDB 支持大数据存储，适合大数据场景需要水平扩展：MongoDB 支持水平扩展，适合大规模数据选择 Memcached 的场景需要简单的缓存：Memcached 只支持简单的键值对，适合简单的缓存场景不需要持久化：Memcached 不支持持久化，适合临时数据不需要复杂操作：Memcached 只支持简单的 GET/SET 操作，适合简单场景5. 混合使用方案在实际项目中，通常会混合使用多种数据库：Redis + MySQLRedis 作为缓存层：缓存热点数据，减轻 MySQL 压力MySQL 作为持久化层：存储持久化数据，保证数据安全读写分离：Redis 处理读操作，MySQL 处理写操作Redis + MongoDBRedis 作为缓存层：缓存热点数据，减轻 MongoDB 压力MongoDB 作为存储层：存储文档型数据，提供灵活的数据结构Redis + MemcachedRedis 作为主缓存：存储需要持久化的数据Memcached 作为辅助缓存：存储临时数据，提高缓存性能总结Redis、MySQL、MongoDB、Memcached 各有优缺点，选择时需要根据具体的业务场景和需求。Redis 适合高性能缓存和实时数据，MySQL 适合持久化存储和复杂查询，MongoDB 适合文档存储和大数据，Memcached 适合简单的缓存场景。在实际项目中，通常会混合使用多种数据库，发挥各自的优势。

Redis

阅读 0·2月19日 19:38

Redis 事务、Lua 脚本和分布式锁的实现原理和使用场景是什么？

Redis 事务、Lua 脚本和分布式锁是 Redis 的高级特性，在实际开发中经常使用。1. Redis 事务基本概念：Redis 事务通过 MULTI、EXEC、DISCARD、WATCH 等命令实现，可以一次性执行多个命令，保证这些命令要么全部执行，要么全部不执行。基本用法：# 开启事务MULTI# 执行命令（命令会被放入队列）SET key1 value1SET key2 value2GET key1# 执行事务EXEC特点：原子性：事务中的命令要么全部执行，要么全部不执行隔离性：事务执行过程中，其他客户端的命令不会插入不支持回滚：Redis 事务不支持回滚，如果某个命令执行失败，其他命令仍会执行WATCH 命令：WATCH 命令用于实现乐观锁，在事务执行前监控一个或多个 key，如果在事务执行前这些 key 被其他客户端修改，事务将不会执行。# 监控 keyWATCH balance# 开启事务MULTI# 执行命令DECRBY balance 100# 执行事务（如果 balance 被其他客户端修改，事务将不会执行）EXEC事务的局限性：不支持条件判断不支持循环不支持复杂逻辑2. Lua 脚本基本概念：Lua 脚本可以在 Redis 服务器端执行，支持复杂的逻辑操作，保证原子性。基本用法：# 执行 Lua 脚本EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 mykey myvalue# 加载脚本并返回脚本 SHASCRIPT LOAD "return redis.call('SET', KEYS[1], ARGV[1])"# 使用 SHA 执行脚本EVALSHA <sha> 1 mykey myvalueLua 脚本的优势：原子性：Lua 脚本执行期间，其他客户端的命令不会插入减少网络往返：多个操作可以在服务器端一次性完成支持复杂逻辑：支持条件判断、循环等复杂逻辑复用性：脚本可以重复使用，提高性能Lua 脚本示例：示例一：实现分布式锁-- 获取锁if redis.call("SETNX", KEYS[1], ARGV[1]) == 1 then redis.call("EXPIRE", KEYS[1], ARGV[2]) return 1else return 0end示例二：限流器-- 限流器local key = KEYS[1]local limit = tonumber(ARGV[1])local current = tonumber(redis.call("GET", key) or "0")if current + 1 > limit then return 0else redis.call("INCR", key) redis.call("EXPIRE", key, ARGV[2]) return 1end示例三：原子操作-- 原子操作：只有当 key 的值等于 expected 时才更新local current = redis.call("GET", KEYS[1])if current == ARGV[1] then redis.call("SET", KEYS[1], ARGV[2]) return 1else return 0endLua 脚本的注意事项：Lua 脚本执行时间不能过长，否则会阻塞 RedisLua 脚本中不能使用随机函数，否则会导致脚本在不同节点执行结果不一致Lua 脚本中不能使用阻塞命令3. 分布式锁基本概念：分布式锁用于在分布式系统中实现互斥访问，确保同一时间只有一个客户端能够访问共享资源。实现方式一：SETNX + EXPIREpublic boolean tryLock(String key, String value, int expireTime) { // 使用 SETNX 设置锁 Long result = redis.setnx(key, value); if (result == 1) { // 设置过期时间 redis.expire(key, expireTime); return true; } return false;}public void unlock(String key, String value) { // 只有锁的持有者才能释放锁 String currentValue = redis.get(key); if (value.equals(currentValue)) { redis.del(key); }}实现方式二：SET NX EX（推荐）public boolean tryLock(String key, String value, int expireTime) { // 使用 SET NX EX 命令，原子性设置锁和过期时间 String result = redis.set(key, value, "NX", "EX", expireTime); return "OK".equals(result);}public void unlock(String key, String value) { // 使用 Lua 脚本保证原子性 String script = "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end"; redis.eval(script, Collections.singletonList(key), Collections.singletonList(value));}实现方式三：Redlock 算法Redlock 是 Redis 官方推荐的分布式锁算法，适用于 Redis Cluster 场景。public boolean tryLock(String key, String value, int expireTime) { // 获取多个 Redis 节点的锁 int successCount = 0; for (RedisClient client : redisClients) { if (client.set(key, value, "NX", "EX", expireTime).equals("OK")) { successCount++; } } // 如果大多数节点获取锁成功，则认为获取锁成功 return successCount > redisClients.size() / 2;}分布式锁的注意事项：锁的过期时间：需要设置合理的过期时间，避免死锁锁的续期：对于长时间任务，需要实现锁的续期机制锁的可重入性：同一个线程可以多次获取同一个锁锁的释放：只有锁的持有者才能释放锁Redisson 分布式锁：Redisson 是一个功能强大的 Redis 客户端，提供了完整的分布式锁实现。// 获取锁RLock lock = redisson.getLock("myLock");try { // 尝试获取锁，最多等待 10 秒，锁自动释放时间为 30 秒 boolean locked = lock.tryLock(10, 30, TimeUnit.SECONDS); if (locked) { // 执行业务逻辑 }} finally { // 释放锁 lock.unlock();}4. 事务 vs Lua 脚本 vs 分布式锁| 特性 | 事务 | Lua 脚本 | 分布式锁 ||------|------|----------|---------|| 原子性 | 支持 | 支持 | 支持 || 复杂逻辑 | 不支持 | 支持 | 不支持 || 网络往返 | 多次 | 一次 | 多次 || 适用场景 | 简单批量操作 | 复杂逻辑操作 | 互斥访问 |5. 最佳实践使用事务的场景：需要原子性执行多个简单命令不需要条件判断和循环使用 Lua 脚本的场景：需要原子性执行多个复杂命令需要条件判断和循环需要减少网络往返使用分布式锁的场景：需要在分布式系统中实现互斥访问需要防止并发问题总结Redis 事务、Lua 脚本和分布式锁是 Redis 的高级特性，各有其适用场景。事务适合简单的批量操作，Lua 脚本适合复杂的逻辑操作，分布式锁适合互斥访问。在实际开发中，需要根据具体的业务场景，选择合适的技术方案。同时，需要注意这些技术的局限性和注意事项，确保系统的稳定性和可靠性。

Redis

阅读 0·2月19日 19:38

Redis 常见问题有哪些？如何解决这些问题？

Redis 在使用过程中会遇到各种常见问题，了解这些问题及其解决方案对于保证 Redis 的稳定性和性能至关重要。1. Redis 为什么这么快？原因分析基于内存存储：Redis 将所有数据存储在内存中，内存的读写速度远快于磁盘内存访问时间在纳秒级别，而磁盘访问时间在毫秒级别单线程模型：Redis 使用单线程模型处理命令，避免了多线程的上下文切换和锁竞争单线程模型简化了实现，减少了并发问题I/O 多路复用：Redis 使用 I/O 多路复用模型（epoll、kqueue、select），可以同时处理多个客户端连接I/O 多路复用避免了阻塞，提高了并发处理能力高效的数据结构：Redis 使用了高效的数据结构，如 SDS、跳跃表、压缩列表等这些数据结构针对特定场景进行了优化，提高了操作效率优化的命令执行：Redis 的命令执行经过了高度优化，减少了不必要的操作使用了批量操作（Pipeline）减少网络往返2. Redis 为什么选择单线程？优势避免上下文切换：多线程需要频繁的上下文切换，消耗 CPU 资源单线程避免了上下文切换，提高了 CPU 利用率避免锁竞争：多线程需要使用锁来保证数据一致性，锁竞争会降低性能单线程不需要锁，避免了锁竞争带来的性能损失简化实现：单线程模型简化了实现，减少了并发问题的复杂性代码更容易维护和调试内存友好：单线程模型对 CPU 缓存更友好，提高了缓存命中率为什么单线程仍然高性能？Redis 的瓶颈不在 CPU：Redis 的瓶颈主要在网络 I/O 和内存访问，而不是 CPU单线程足以处理网络 I/O 和内存访问I/O 多路复用：Redis 使用 I/O 多路复用，可以同时处理多个客户端连接单线程可以高效地处理多个连接基于内存：Redis 基于内存存储，内存访问速度极快单线程可以充分利用内存的高性能多线程 RedisRedis 6.0 引入了多线程，主要用于网络 I/O 的读写：网络 I/O 多线程：网络 I/O 的读写使用多线程，提高网络处理能力命令执行单线程：命令执行仍然使用单线程，保证数据一致性3. Redis 如何保证数据一致性？缓存一致性问题：缓存和数据库的数据不一致，导致读取到脏数据解决方案：方案一：Cache Aside Pattern// 读操作public User getUserById(Long id) { User user = redis.get("user:" + id); if (user != null) { return user; } user = db.queryUserById(id); redis.set("user:" + id, user, 3600); return user;}// 写操作public void updateUser(User user) { db.updateUser(user); redis.del("user:" + user.getId());}方案二：延时双删public void updateUser(User user) { db.updateUser(user); redis.del("user:" + user.getId()); // 第一次删除 try { Thread.sleep(500); // 延时 } catch (InterruptedException e) { e.printStackTrace(); } redis.del("user:" + user.getId()); // 第二次删除}方案三：订阅 Binlog// 订阅数据库的 Binlog，当数据库变更时，自动更新缓存@CanalEventListenerpublic class CacheUpdateListener { @ListenPoint(destination = "example", schema = "test", table = "user") public void onEvent(CanalEntry.Entry entry) { // 解析 Binlog，更新缓存 User user = parseUserFromBinlog(entry); redis.set("user:" + user.getId(), user, 3600); }}主从一致性问题：主从复制存在延迟，导致从节点读取到旧数据解决方案：方案一：读写分离// 写操作使用主节点public void updateUser(User user) { masterRedis.set("user:" + user.getId(), user);}// 读操作使用从节点public User getUserById(Long id) { return slaveRedis.get("user:" + id);}方案二：强制读主节点// 对于需要强一致性的数据，强制读主节点public User getUserByIdWithConsistency(Long id) { return masterRedis.get("user:" + id);}4. Redis 如何处理大 Key？大 Key 的危害内存占用高：大 Key 占用大量内存，影响其他数据的存储性能问题：大 Key 的读写操作耗时较长，影响 Redis 性能大 Key 的删除操作会阻塞 Redis，导致其他请求等待主从同步慢：大 Key 的主从同步耗时较长，影响主从同步效率解决方案方案一：拆分大 Key// 将大 Key 拆分成多个小 Keypublic void setBigKey(String key, String value) { int chunkSize = 1024; // 每个块 1KB for (int i = 0; i < value.length(); i += chunkSize) { String chunk = value.substring(i, Math.min(i + chunkSize, value.length())); redis.set(key + ":" + i, chunk); }}public String getBigKey(String key) { StringBuilder sb = new StringBuilder(); int i = 0; while (true) { String chunk = redis.get(key + ":" + i); if (chunk == null) { break; } sb.append(chunk); i++; } return sb.toString();}方案二：使用 Hash// 使用 Hash 存储大对象public void setBigObject(String key, Map<String, String> data) { for (Map.Entry<String, String> entry : data.entrySet()) { redis.hset(key, entry.getKey(), entry.getValue()); }}public Map<String, String> getBigObject(String key) { return redis.hgetAll(key);}方案三：异步删除// 使用 UNLINK 命令异步删除大 Keypublic void deleteBigKey(String key) { redis.unlink(key); // 异步删除，不会阻塞 Redis}5. Redis 如何处理热点 Key？热点 Key 的危害单节点压力：热点 Key 集中在某个节点，导致该节点压力过大性能瓶颈：热点 Key 的访问量过大，导致性能瓶颈解决方案方案一：读写分离// 读操作使用从节点public User getUserById(Long id) { return slaveRedis.get("user:" + id);}方案二：本地缓存// 使用本地缓存减少 Redis 访问public User getUserById(Long id) { // 先查本地缓存 User user = localCache.get("user:" + id); if (user != null) { return user; } // 再查 Redis user = redis.get("user:" + id); if (user != null) { localCache.put("user:" + id, user); } return user;}方案三：热点 Key 拆分// 将热点 Key 拆分成多个 Keypublic void setHotKey(String key, String value) { int shardCount = 10; for (int i = 0; i < shardCount; i++) { redis.set(key + ":" + i, value); }}public String getHotKey(String key) { int shard = (int) (Math.random() * 10); return redis.get(key + ":" + shard);}6. Redis 如何实现分布式锁？实现方式方案一：SET NX EXpublic boolean tryLock(String key, String value, int expireTime) { String result = redis.set(key, value, "NX", "EX", expireTime); return "OK".equals(result);}public void unlock(String key, String value) { String script = "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end"; redis.eval(script, Collections.singletonList(key), Collections.singletonList(value));}方案二：Redlockpublic boolean tryLock(String key, String value, int expireTime) { int successCount = 0; for (RedisClient client : redisClients) { if (client.set(key, value, "NX", "EX", expireTime).equals("OK")) { successCount++; } } return successCount > redisClients.size() / 2;}方案三：Redissonpublic void doWithLock(String lockKey, Runnable task) { RLock lock = redisson.getLock(lockKey); try { lock.lock(); task.run(); } finally { lock.unlock(); }}7. Redis 如何实现限流？实现方式方案一：固定窗口public boolean allowRequest(String key, int limit, int expireTime) { String count = redis.get(key); if (count == null) { redis.set(key, "1", expireTime); return true; } int currentCount = Integer.parseInt(count); if (currentCount < limit) { redis.incr(key); return true; } return false;}方案二：滑动窗口public boolean allowRequestSliding(String key, int limit, int windowSize) { long currentTime = System.currentTimeMillis(); long windowStart = currentTime - windowSize; redis.zremrangeByScore(key, 0, windowStart); redis.zadd(key, currentTime, UUID.randomUUID().toString()); long count = redis.zcard(key); return count <= limit;}方案三：令牌桶public boolean allowRequestTokenBucket(String key, int capacity, int rate) { String script = "local tokens = tonumber(redis.call('get', KEYS[1])) or 0" + "tokens = math.min(tokens + ARGV[1], ARGV[2])" + "if tokens >= 1 then" + " redis.call('set', KEYS[1], tokens - 1)" + " return 1" + "else" + " redis.call('set', KEYS[1], tokens)" + " return 0" + "end"; return redis.eval(script, Collections.singletonList(key), Collections.singletonList(rate), Collections.singletonList(capacity)) == 1;}总结Redis 在使用过程中会遇到各种常见问题，包括性能问题、一致性问题、大 Key 问题、热点 Key 问题等。了解这些问题及其解决方案，对于保证 Redis 的稳定性和性能至关重要。在实际应用中，需要根据具体的业务场景，选择合适的解决方案。

Redis

阅读 0·2月19日 19:38

Redis 性能优化有哪些策略？如何提高 Redis 的性能？

Redis 性能优化是一个系统工程，需要从多个维度进行优化。以下是 Redis 性能优化的关键策略：1. 内存优化选择合适的数据结构：使用 Hash 存储对象，而不是多个 String使用 ZSet 存储排行榜，而不是 List使用 Bitmap 存储布尔值，而不是 Set使用 HyperLogLog 进行基数统计，而不是 Set控制键的命名：使用简短但有意义的键名，减少内存占用避免过长的键名，如 user:profile:1001:detail:info 可以简化为 u:1001:pf使用压缩列表：Hash 和 List 在元素较少时会自动使用 ziplist调整 hash-max-ziplist-entries 和 hash-max-ziplist-value 参数调整 list-max-ziplist-size 参数设置过期时间：为临时数据设置合理的过期时间，避免内存泄漏使用 EXPIRE、EXPIREAT、TTL 等命令管理过期时间2. 网络优化使用 Pipeline：Pipeline 可以将多个命令打包发送，减少网络往返次数适合批量操作，如批量插入、批量查询# 使用 Pipeline 批量设置echo -e "SET key1 value1\nSET key2 value2\nSET key3 value3" | redis-cli --pipe使用连接池：客户端使用连接池，避免频繁创建和销毁连接合理设置连接池大小，避免连接数过多减少大 Key：大 Key 会导致网络传输慢、内存占用高将大 Key 拆分成多个小 Key使用 Hash 存储大对象，而不是 String禁用 THP（Transparent Huge Pages）：echo never > /sys/kernel/mm/transparent_hugepage/enabled3. CPU 优化避免使用 KEYS 命令：KEYS 命令会阻塞 Redis，导致性能问题使用 SCAN 命令替代 KEYS，进行增量迭代# 使用 SCAN 替代 KEYSSCAN 0 MATCH user:* COUNT 100避免使用复杂操作：避免使用大范围的 SORT 操作避免使用 SUNION、SINTER 等大集合操作使用 Lua 脚本减少网络往返使用 Lua 脚本：Lua 脚本在服务器端执行，减少网络往返适合复杂的原子操作-- 使用 Lua 脚本实现原子操作if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1])else return 0end4. 持久化优化合理配置 RDB：调整 RDB 保存频率，避免过于频繁在低峰期进行 RDB 保存关闭 RDB 压缩可以提高性能，但会增加文件大小合理配置 AOF：使用 appendfsync everysec 平衡性能和数据安全调整 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size在低峰期进行 AOF 重写使用混合持久化：开启 aof-use-rdb-preamble yes，兼顾性能和数据安全5. 集群优化数据分片：使用 Redis Cluster 进行数据分片，提高并发能力合理分配哈希槽，避免数据倾斜读写分离：使用主从复制，将读操作分散到从节点使用哨兵模式实现自动故障转移负载均衡：客户端实现负载均衡，将请求分散到不同节点使用一致性哈希算法，减少节点变更时的数据迁移6. 监控和调优使用 Redis 慢查询日志：# 配置慢查询日志CONFIG SET slowlog-log-slower-than 10000 # 10msCONFIG SET slowlog-max-len 128# 查看慢查询SLOWLOG GET 10使用 INFO 命令监控：# 查看内存使用情况INFO memory# 查看命令执行情况INFO commandstats# 查看连接情况INFO clients使用 Redis Benchmark：# 性能测试redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100007. 操作系统优化调整文件描述符限制：# 临时调整ulimit -n 65535# 永久调整echo "* soft nofile 65535" >> /etc/security/limits.confecho "* hard nofile 65535" >> /etc/security/limits.conf调整 TCP 参数：# 启用 TCP 快速打开echo 3 > /proc/sys/net/ipv4/tcp_fastopen# 调整 TCP 缓冲区大小echo "net.core.rmem_max = 16777216" >> /etc/sysctl.confecho "net.core.wmem_max = 16777216" >> /etc/sysctl.conf8. 客户端优化使用高性能客户端：选择性能好的 Redis 客户端，如 Jedis、Lettuce、Redisson使用异步客户端，提高并发能力合理使用缓存：客户端本地缓存热点数据，减少 Redis 访问使用多级缓存策略，如本地缓存 + Redis 缓存避免 N+1 查询：使用 Pipeline 或 MGET 批量查询使用 Hash 存储相关数据，减少查询次数9. 架构优化使用 Redis Proxy：使用 Twemproxy、Codis 等 Redis Proxy，实现分片和负载均衡减少客户端的复杂度使用 Redis Sentinel：使用哨兵模式实现高可用自动故障转移，提高系统可靠性使用 Redis Cluster：使用集群模式实现水平扩展提高系统的并发能力和数据容量总结Redis 性能优化需要从多个维度进行，包括内存优化、网络优化、CPU 优化、持久化优化、集群优化、监控和调优、操作系统优化、客户端优化和架构优化。在实际应用中，需要根据具体的业务场景和性能瓶颈，选择合适的优化策略。同时，需要持续监控 Redis 的运行状态，及时发现和解决性能问题。

Redis

阅读 0·2月19日 19:38

Redis 的主从复制、哨兵模式和集群模式有什么区别？如何选择？

Redis 提供了三种集群方案：主从复制、哨兵模式和集群模式，它们各有不同的适用场景和特点。1. 主从复制（Master-Slave Replication）工作原理：主从复制是指将一个 Redis 节点作为主节点（Master），其他节点作为从节点（Slave）。主节点负责写操作，从节点负责读操作。主节点将数据变更同步到从节点。特点：读写分离：主节点处理写操作，从节点处理读操作，提高系统吞吐量数据备份：从节点是主节点的完整副本，提供数据冗余故障恢复：主节点故障时，需要手动将从节点提升为主节点配置方式：# 在从节点配置文件中添加slaveof <master-ip> <master-port>缺点：主节点故障时需要手动切换，无法自动故障转移主节点的写能力受限，无法水平扩展2. 哨兵模式（Sentinel）工作原理：哨兵模式是在主从复制的基础上，增加了哨兵节点。哨兵节点监控主从节点的运行状态，当主节点故障时，自动将从节点提升为主节点，实现自动故障转移。特点：自动故障转移：主节点故障时，自动选举新的主节点监控：实时监控主从节点的健康状态通知：当主节点故障时，通知管理员配置提供者：客户端可以从哨兵获取当前主节点的地址哨兵工作流程：哨兵定期向主从节点发送 PING 命令检查健康状态如果主节点在指定时间内无响应，哨兵会标记主节点为主观下线当足够多的哨兵都认为主节点下线时，主节点被标记为客观下线哨兵选举出一个领头哨兵，负责故障转移领头哨兵从从节点中选举出新的主节点其他从节点重新配置，指向新的主节点配置方式：# 哨兵配置文件 sentinel.confport 26379sentinel monitor mymaster 127.0.0.1 6379 2sentinel down-after-milliseconds mymaster 30000sentinel parallel-syncs mymaster 1sentinel failover-timeout mymaster 180000缺点：主节点的写能力仍然受限，无法水平扩展哨兵节点本身也可能成为单点故障3. 集群模式（Cluster）工作原理：Redis Cluster 采用去中心化的架构，将数据分片存储在多个节点上。每个节点负责一部分数据，通过哈希槽（Hash Slot）实现数据分片。特点：数据分片：将数据分散到多个节点，实现水平扩展高可用：每个主节点可以有多个从节点，主节点故障时自动故障转移无中心节点：所有节点地位平等，没有单点故障自动故障转移：主节点故障时，从节点自动提升为主节点哈希槽机制：Redis Cluster 共有 16384 个哈希槽（0-16383）每个节点负责一部分哈希槽使用 CRC16(key) % 16384 计算键对应的哈希槽客户端根据哈希槽定位到对应的节点配置方式：# 集群配置文件 redis.confcluster-enabled yescluster-config-file nodes.confcluster-node-timeout 5000cluster-require-full-coverage yes创建集群：redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 \127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \--cluster-replicas 1缺点：不支持多键操作（除非这些键在同一个哈希槽）客户端需要支持集群协议事务支持有限三种方案对比| 特性 | 主从复制 | 哨兵模式 | 集群模式 ||------|---------|---------|---------|| 数据分片 | 不支持 | 不支持 | 支持 || 自动故障转移 | 不支持 | 支持 | 支持 || 读写分离 | 支持 | 支持 | 支持 || 水平扩展 | 不支持 | 不支持 | 支持 || 复杂度 | 低 | 中 | 高 || 适用场景 | 简单读写分离 | 高可用场景 | 大规模数据 |选择建议数据量小，需要读写分离：使用主从复制数据量小，需要高可用：使用哨兵模式数据量大，需要水平扩展：使用集群模式生产环境推荐：使用哨兵模式或集群模式，根据数据量选择在实际应用中，大多数生产环境会选择哨兵模式或集群模式，以确保系统的高可用性和可扩展性。

Redis

阅读 0·2月19日 19:37

1
•••
4
5
6
7
8
•••
62