为什么Codis比较慢，但我们还要用它呢？

最新推荐文章于 2024-06-18 19:34:55 发布
最新推荐文章于 2024-06-18 19:34:55 发布
阅读量244 收藏
点赞数
CC 4.0 BY-SA版权
文章标签： 数据库 epoll
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_34303897/article/details/85022848
本文探讨了Codis相较于Twemproxy在性能上的差异，指出Codis因追求简洁实现及Go语言特性，在单CPU情况下性能较低。尽管如此，Codis在横向扩展能力、动态调整方面具有优势。

  1. 为什么 Codis 比 twemproxy 慢？

  • Codis 追求简洁的实现，我们没有针对内存进行优化，所以会比 twemproxy 还要多一倍拷贝。

  • Go 虽然使用 epoll，但是 IO 都不是直接完成的，而是通过 IO thread，所以需要更多的线程间通信和线程切换。

  • 所以单 CPU 情况下， Codis 吞吐能到 twemproxy 的 1/2，redis 的 1/4，说明我的实现还是可以的。

  • Codis 是 Go 开发的，底层 IO 本质也是通过 epoll 实现的。Go 为开发带来了方便，但是所有的便利都是以牺牲性能作为代价的。

那需要 Codis 有什么用？

  • 单 twemproxy：方便调整，性能不行

  • 多 twemproxy：调整需要技巧，可能需要停止服，看具体业务需求，无论如何都很痛苦。

  • Codis？

  • 适当的 CPU 就可以获得比 twemproxy 更好的性能和可靠性，同时具备横向扩展的能力

  • 可动态调整。这一点就足够了。

  • 对 redis 集群而言，CPU 和 内存，哪个更贵？而且通常 redis 集群 CPU 都是空闲的

  • 如果你的业务需要 10G：没必要用 twemproxy 或者 Codis，影响心情，给自己添麻烦。

  • 如果你的业务需要 400G：你可以选择 单/多 twemproxy + 多 redis，毕竟在相同吞吐下，twemproxy 比 codis 有更好地 CPU 利用率。

  • 但是一旦你的业务需要迁移数据，比如机器上下线，容量调整，怎么办？


转载自https://github.com/CodisLabs/codis/issues/309

【redis】redis 分而治之 Codis
九师兄
12-06 998
觉得写的好，收集一下，便于自己查找。在大数据高并发场景下，单个 Redis 实例往往会显得捉襟见肘。首先体现在内存上，单个 Redis 的内存不宜过大，内存太大会导致 rdb 文件过大，进一步导致主从同步时全量同步时间过长，在实例重启恢复时也会消耗很长的数据加载时间，特别是在云环境下，单个实例内存大小往往都是受限的。其次体现在 CPU 的利用率上，单Redis 实例只能利用单个核心，这单个核心要完成海量数据的存取和管理工作，压力会非常大。
游戏服务端究竟解决了什么问题？
走向CTO的路上...
04-10 1910
转自：http://www.yilan.io/article/5775f60463da75a05a5dcd95 1.写在前面 既然是游戏服务端程序员，那博客里至少还是得有一篇跟游戏服务端有关的文章，今天文章主题就关于游戏服务端。写这篇博客之前也挺纠结的，一方面是因为游戏服务端其实不论架构上还是具体一些逻辑模块的构建，都属于非常成熟的技术，举个简单的例子，像端游的多zone/scene/ga
为什么大厂都喜欢用 Codis 来管理分布式集群？
sky198989的博客
06-27 204
转载：https://juejin.im/post/5c132b076fb9a04a08218eef
Redis集群高可用性方案-Codis
藏经阁
04-05 697
在大数据高并发场景下，单个 Redis 实例往往会显得捉襟见肘。首先体现在内存上，单 个 Redis 的内存不宜过大，内存太大会导致 rdb 文件过大，进一步导致主从同步时全量同 步时间过长，在实例重启恢复时也会消耗很长的数据加载时间，特别是在云环境下，单个实 例内存往往都是受限的。其次体现在 CPU 的利用率上，单个 Redis 实例只能利用单个核 心，这单个核心要完成海量数据的存取和管理工作压...
高效运维最佳实践（03）：Redis集群技术及Codis实践 (转)
guo_yang的博客
06-10 619
专栏介绍 “高效运维最佳实践”是InfoQ在2015年推出的精品专栏，由触控科技运维总监萧田国撰写，InfoQ总编辑崔康策划。 前言 诚如开篇文章所言，高效运维包括管理的专业化和技术的专业化。前两篇我们主要在说些管理相关的内容，本篇说一下技术专业化。希望读者朋友们能适应这个转换，谢谢。 互联网早在几年前就已进入Web 2.0时代，对后台支撑能力的要求，提高了几十倍甚至几百倍。在这个演化过程...
codis介绍
MyObject-C的专栏
12-13 3719
分片介绍 介绍codis前，先介绍下分片知识 分片(partitioning)就是将你的数据拆分到多个 Redis 实例的过程，这样每个实例将只包含所有键的子集。 分片能做什么 Redis 的分片承担着两个主要目标： 允许使用很多电脑的内存总和来支持更大的数据库。没有分片，你就被局限于单机能支持的内存容量。 允许伸缩计算能力到多核或多服务器，伸缩网络带宽到多服务器或多网络适配器。 分片...
Redis故障检查：识别慢查询操作
大力海棠的博客
06-21 899
目录 运行状态信息 持久化信息 识别慢查询 前几篇日志总结了下对Redis部署时的一些配置，Redis启动后，面对各种请求，数据持久化到硬盘，很可能会出现内存不足等故障问题，导致Redis速度变慢甚至崩溃。在Redis运行前我们可以做很多配置防止这些问题的出现，在Redis运行后，面对未知的突发情况，出现问题了，其实我们也可以用一些命令查看，发现它，例如使用SLOWLOG命令查看Redis中的慢查询操作。 运行状态信息 Redis运行后，怎么查看它的运行状态来判断当...
Redis 中数据增多了，是该加内存还是加实例？
swadian2008的博客
09-28 362
在应对数据量扩容时，虽然增加内存这种纵向扩展的方法简单直接，但是会造成数据库的内存过大，导致性能变慢。Redis 切片集群提供了横向扩展的模式，也就是使用多个实例，并给每个实例配置一定数量的哈希槽，数据可以通过键的哈希值映射到哈希槽，再通过哈希槽分散保存到不同的实例上。这样做的好处是扩展性好，不管有多少数据，切片集群都能应对。// 计算数据的Hash槽，确定具体的存储实例。
[面试题]Redis
春暖花开的日子
06-18 1035
一次请求/响应服务器能实现处理新的请求即使旧的请求还未被响应。这样就可以将多个命令发送到服务器，而不用等待回复，最后在一个步骤中读取该答复。注意，Redis Pipelining 是 Redis Client 实现的功能，而不是 Redis Server 提供的特性。假设我们有 3 个请求进行下举例子。未使用 Pipeline 时，那么整个执行的顺序是，req1->resp1->req2->resp2->req3->resp3。
Redis一问多答（必背篇）
weixin_42031763的博客
08-22 3797
目录 1.Redis怎么使用？ 2.redis为什么快？redis的线程模型 3.redis常用数据结构的底层 1.string 2.list 3.Hash 4.set 5.zset 拓展：为什么SDS最大存储44字节后，编码就从embstr转为raw？ 4.缓存穿透如何解决？布隆过滤器 原理： 优点： 缺点： 实现： 总结： 5.什么是大Key和热Key，会造成什么问题，如何解决？系统在某个时刻访问量剧增（热点新闻），造成数据库压力剧增甚至崩溃，怎么办？ Big Key
Redis面试题-Redis变慢定位
haicoder_ibai的博客
03-25 366
本文参考 嗨客网 Redis面试题 Redis变慢定位 Redis变慢定位 Redis 作为内存数据库，拥有非常高的性能，单个实例的 QPS 能够达到 10W 左右。但我们在使用 Redis 时，经常时不时会出现访问延迟很大的情况，如果你不知道 Redis 的内部实现原理，在排查问题时就会一头雾水。 很多时候，Redis 出现访问延迟变大，都与我们的使用不当或运维不合理导致的。 Redis变慢常见原因 使用复杂度高的命令 如果在使用 Redis 时，发现访问延迟突然增大，如何进行排查？首先，第一步，建.
【架构】深入浅出百亿请求高可用Redis(codis)分布式集群揭秘
lisheng19870305的专栏
04-25 635
摘要：作为noSql中的kv数据库的王者，redis以其高性能，低时延，丰富的数据结构备受开发者青睐，但是由于redis在水平伸缩性上受限，如何做到能够水平扩容，同时对业务无侵入性是很多使用redis的开发人员都会面临的问题，而redis分布式解决方案的一个开源产品【codis】较好的弥补了这一弱势，本文主要讲解codis是如何做到对业务无感知，平滑迁移，迁移性能高，迁移异常处理，高可用以及常见的redis的避坑指南，虽然codis目前随着公司的nosql产品越来越成熟，生命周期也即将结束，不过鉴于还有很多
Codis 千万并发下调优
weixin_34159110的博客
01-30 1454
环境： 8台机器 32C 256G,redis 6主6从在同一台机器上，dashbaord也在redis00上。codis-proxy 开8C，每台机器开2个proxy。万M网络，CentosOS 6.5 内核2.6.32-431.el6.x86_64。 现象： sprak 70台机器 向codis写 开启pipline,不控制pipline大小...
Codis VS redis-cluster简单比较
melody's blog
11-30 7424
Codis Redis-cluster 备注 Redis版本 2.8.13分支开发 >= 3.0   部署 较复杂。 简单   运维 Dashboard,运维方便。 运维人员手动通过命令操作。   监控 可在
为什么那么多大公司喜欢用Codis来管理redis分布式集群？
bodouer7979的博客
07-09 392
Redis 集群，顾名思义就是使用多个 Redis 节点构成的集群，从而满足在数据量和并发数大的业务需求。在单个 Redis 的节点实例下，存储的数据量大和高并发的情况下，内存很容易就暴涨。同时，一个 Redis 的节点，内存也是受限的，两个原因，一个是内存过大，在进行数据同步的时候，全量同步的时候会导致时间过长，会增加同步失败的风险；另一个原因就是一般的 Redis 都是部...
codis解决方案
Devops学习旅途
11-07 449
codis是比较成熟的redis集群解决方案，在使用过程中，遇到过一些常见的问题。 1、codis-dashboard 异常退出 codis-dashboard如果是正常kill命令退出的话，会去zookeeper或者etcd或者文件系统上删除注册信息。但是如果是异常退出，这些注册信息就还在，会导致重启dashboard失败。这时候就需要使用codis-admin删除注册信息。 操作步骤：...
Codis安装与部署
Sun__s的博客
01-15 336
一、Codis简介 Codis是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 (不支持的命令列表), 上层应用可以像使用单机的 Redis 一样使用, Codis 底层会处理请求的转发, 不停机的数据迁移等工作, 所有后边的一切事情, 对于前面的客户端来说是透明的, 可以简单的认为后边连接的是一个内存无限大的 Redis 服务. 二、特性 自动平衡 使用非常简单 图形化的面板和管理工具 支持绝大多
redis 慢查询日志
热门推荐
白日梦
07-19 1万+
Slowlog命令用于读取和重新设置redis慢查询日志.概述redis 慢查询日志, 是系统记录那些超过指定查询时间的日志. 执行的时间不包括和客户端的IO操作，和响应时间等, 而只是实际redis执行命令的时间(只是线程执行命令时，阻塞不能在接受处理其他请求花费的时间)慢查询日志有两个参数： - slowlog-log-slower-than: 单位微妙，指定redis执行命令的最大时间，
面试题问题及答案
最新发布
03-11
<think>嗯，用户现在想要的是面试题问题及答案。之前已经给过他们一个Java架构师面试题的梳理，现在他们可能想要更具体的题目和对应的答案。我需要分析他们的需求，看看他们是不是在准备面试，需要实际的例子来练习。 首先，用户之前的请求是关于Java架构师面试题的介绍，现在则是直接要求“面试题问题及答案”，可能希望得到更详细的问题和解答示例。他们可能已经在准备面试，需要具体的题目来测试自己的知识，或者作为复习材料。 接下来，我需要确保回答的结构清晰，问题分类合理，答案准确。根据之前的回答，用户可能期望类似的分类，比如Java核心、系统设计、数据库等，每个部分都有几个典型问题和答案。 还要注意用户提到的系统级指令，比如使用正确的LaTeX格式，行内公式用$...$，独立公式用$$...$$。需要检查答案中的技术术语是否有正确的格式，例如在讲解Snowflake算法时，确保公式用$$包裹。 另外，用户希望用中文回答，所以所有内容都需要用中文表达，避免术语混淆。同时，答案要真实可靠，可能需要参考常见的面试题和权威解答，避免错误信息。 可能还需要考虑用户是否需要更深入的问题，或者更基础的题目，但根据之前的交互，用户关注的是架构师级别的面试题，所以问题应该偏向高级主题，如分布式系统、微服务、性能优化等。 需要确保每个问题都有简洁但完整的答案，例如在解释CAP理论时，要明确各个原则的含义和实际应用。同时，示例问题解答部分要具体，比如分布式ID生成的三种方法，用LaTeX公式展示Snowflake算法，这样更直观。 最后，检查是否有遗漏的重要主题，比如框架相关的问题（Spring、Spring Boot）、设计模式、JVM调优等，确保覆盖Java架构师面试的核心领域。同时，开放性问题如项目经验和技术趋势也不能少，帮助用户全面准备。</think>以下是一些典型的 **Java架构师面试题及参考答案**，涵盖核心知识点和设计场景，帮助您针对性准备： --- ### **一、Java核心与JVM** **1. 如何解决`OutOfMemoryError`问题？** - **分析步骤**： 1. 使用`jstat`或VisualVM监控堆内存变化 2. 通过`-XX:+HeapDumpOnOutOfMemoryError`生成堆转储文件 3. 用MAT工具分析大对象（如内存泄漏的集合类） - **常见原因**：未关闭的数据库连接、静态集合长期持有对象、大文件未流式读取 **2. `synchronized`和`ReentrantLock`的区别？** - **锁机制**：`synchronized`是JVM层面的隐式锁；`ReentrantLock`是API层面的显式锁 - **功能对比**： - `ReentrantLock`支持公平锁、可中断锁、多条件变量 - `synchronized`自动释放锁，代码更简洁 --- ### **二、分布式系统** **1. 如何实现分布式锁？** - **方案1（Redis）**： ```java // 使用SET命令+过期时间（防止死锁） String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime); if ("OK".equals(result)) { // 获取锁成功 } ``` - **方案2（ZooKeeper）**：通过创建临时有序节点实现，Watch机制监听节点删除事件 **2. 解释CAP理论并举例** - **定义**： - **C（一致性）**：所有节点数据一致 - **A（可用性）**：每次请求都能获得响应 - **P（分区容忍性）**：网络分区时系统仍能运行 - **取舍案例**： - **CP系统**：ZooKeeper（选举期间拒绝写入） - **AP系统**：Eureka（服务注册表允许短暂不一致） --- ### **三、数据库与缓存** **1. 如何优化慢SQL查询？** - **排查步骤**： 1. 使用`EXPLAIN`分析执行计划，关注`type`（扫描方式）和`Extra`字段 2. 添加索引（避免全表扫描），如联合索引需满足最左匹配原则 3. 优化SQL逻辑（如减少子查询、避免`SELECT *`） **2. 缓存穿透 vs 缓存击穿 vs 缓存雪崩** - **穿透**：查询不存在的数据（解决方案：布隆过滤器拦截非法Key） - **击穿**：热点Key过期后高并发查询压垮DB（解决方案：互斥锁重建缓存） - **雪崩**：大量Key同时过期（解决方案：随机过期时间+二级缓存） --- ### **四、系统设计** **1. 设计一个秒杀系统** - **核心难点**：高并发下的库存超卖与性能瓶颈 - **关键方案**： - **流量削峰**：MQ异步处理请求，客户端轮询结果 - **库存扣减**：Redis预扣库存（Lua脚本保证原子性）+ 数据库最终一致性 - **限流熔断**：Sentinel对突发流量熔断降级 **2. 如何设计API网关的限流？** - **算法选择**： - **令牌桶**：允许突发流量（如Guava的`RateLimiter`） - **漏桶**：恒定速率处理请求 - **实现层级**： - **网关层**：Nginx限流模块或Spring Cloud Gateway的`RequestRateLimiter`过滤器 - **服务层**：AOP切面+Redis计数器（如`INCR`命令） --- ### **五、开放性问题** **1. 如何降低系统耦合度？** - **策略**： 1. 模块化拆分（DDD领域划分） 2. 事件驱动架构（通过MQ解耦服务） 3. 依赖倒置（面向接口编程） **2. 如何管理技术债务？** - **步骤**： 1. 代码扫描工具（如SonarQube）识别高风险代码 2. 制定重构计划（每次迭代预留20%时间处理债务） 3. 建立技术评审机制，防止新增债务 --- ### **六、实战代码题示例** **题目：线程安全的单例模式** ```java public class Singleton { // 双重校验锁+volatile防止指令重排序 private static volatile Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } } ``` --- ### **总结建议** 1. **原理优先**：面试官常追问底层机制（如“ConcurrentHashMap如何保证线程安全？”需答分段锁/CAS） 2. **场景化回答**：结合项目说明技术选型原因（如“为什么选择Kafka而非RabbitMQ？”） 3. **横向对比**：同类技术的优缺点（如Redis Cluster vs Codis） 附：**分布式ID生成公式（Snowflake算法）** $$ \text{ID} = \text{41位时间戳} \ |\ \text{10位机器ID} \ |\ \text{12位序列号} $$ 通过以上问题及答案的梳理，可系统化提升技术深度与表达逻辑。建议结合自身项目经验，针对性准备案例分析。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值