上期我比较了腾讯云和阿里云的MySQL数据库,文章发布之后引起了一些反响,有质疑数据的,也有希望了解更多细节的同学。其实一个数据库产品的好坏,不光是QPS、TPS这种吞吐量指标,其他特性如主从复制、灾备、稳定性、可视化管理等也起着重要作用,有兴趣的同学可以自己去体验一下,我也会逐步完善这些数据库测试。这期我们来看另一个常用的数据库:Redis。
最近,某客户自建redis迁移上云时出现了容量增加25%的现象。这到底是怎么回事呢?
描述:Redis 通过监听一个 TCP 端口或者 Unix socket(/var/run/redis/redis-server.sock)的方式来接收来自客户端的连接,当一个连接建立后Redis 内部会进行以下一些操作:
之前,我们开源了腾讯云数据库Tendis存储版,同时又对这个产品的适用场景、架构、特性和发展历程进行了分享。 而这次,我们还对Tendis存储版的技术特性进行深度解读。 进入公众号,后台回复“0120刘锐”,即可下载分享PPT。本文将主要分为简介,架构,和特性三个部分展开。 tendis存储版是一款支持redis协议,数据存放在磁盘的存储引擎。架构可以简单的分为三层,一个是tendis的server层,然后是rocksdb的引擎层,底层我们通常采用ssd来提高io速度,当然sata盘也是可以的。我们
上文我们聊了基于Sentinel的Redis高可用架构,了解了Redis基于读写分离的主从架构,同时也知道当Redis的master发生故障之后,Sentinel集群是如何执行failover的,以及其执行failover的原理是什么。
1、Redis 可以用几十G内存来做缓存,Map不行,一般 JVM 也就分几个 G 数据就够大了
一个数据类型都对应了很多种底层数据结构。以List为例,什么情况下是双向链表,反之又在什么情况下是压缩列表呢?还是说是并存状态?
Redis 的复制(replication)功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品,其中被复制的服务器为主服务器(master),而通过复制创建出来的服务器复制品则为从服务器(slave)。 只要主从服务器之间的网络连接正常,主从服务器两者会具有相同的数据,主服务器就会一直将发生在自己身上的数据更新同步 给从服务器,从而一直保证主从服务器的数据相同。
当前内存数据库发展迅速,用户对于存储系统的要求也越来越高,为了满足各类业务场景的需要,腾讯云设计了新一代的内存数据库,不但保留了原来系统的高性能,高可用等特性,同时还兼容了当前流行的Redis原生协议及使用方式。我们试图在解决原生方案短板的基础上,不断创新,使得新系统同时具备易懂、易用、易维护、高可靠、低成本等特点。主要体现在以下几个方面:
问题1:懂Redis事务么? 正常版:Redis事务是一些列redis命令的集合,blabla… 高调版: 我们在生产上采用的是Redis Cluster集群架构,不同的key是有可能分配在不同的Redis节点上的,在这种情况下Redis的事务机制是不生效的。其次,Redis事务不支持回滚操作,简直是鸡肋!所以基本不用!
一 Redis单机缺陷 redis单机容量方面会有瓶颈,主从模式只能保证支撑更多读并发,但是slave和master的数据是一模一样的,也就是说master能存储多少数据,slave就也只能存储这么多
在服务开发中,单机都会存在单点故障的问题,即服务部署在一台服务器上,一旦服务器宕机服务就不可用,所以为了让服务高可用,分布式服务就出现了,将同一服务部署到多台机器上,即使其中几台服务器宕机,只要有一台服务器可用服务就可用。
点击上方蓝色字体,选择“设为星标” 回复”学习资料“获取学习宝典 背景 在服务开发中,单机都会存在单点故障的问题,及服务部署在一台服务器上,一旦服务器宕机服务就不可用,所以为了让服务高可用,分布式服务就出现了,将同一服务部署到多台机器上,即使其中几台服务器宕机,只要有一台服务器可用服务就可用。 redis也是一样,为了解决单机故障引入了主从模式,但主从模式存在一个问题:master节点故障后服务,需要人为的手动将slave节点切换成为maser节点后服务才恢复。redis为解决这一问题又引入了哨兵模式
腾讯云新版本监控(5秒粒度)已经灰度3个多月了,原有的分钟级粒度的监控版本仍然会继续保留一段时间,有条件的企业和开发者推荐升级至5秒监控,后续官方应该会提供合适的升级方案。
1、Redis-Server:Redis服务端,用于存储用户数据的,此处就一个master节点【IP: 100.100.100.1:6379】
持久化是最简单的高可用方法(有时甚至不被归为高可用的手段),主要作用是数据备份,即将数据存储在硬盘,保证数据不会因进程退出而丢失。
点击上方“芋道源码”,选择“设为星标” 管她前浪,还是后浪? 能浪的浪,才是好浪! 每天 10:33 更新文章,每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路,很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
原文地址 http://hi.baidu.com/ywdblog/item/1a8c6ed42edf01866dce3fe3
秒杀活动是绝大部分电商选择的低价促销、推广品牌的方式。不仅可以给平台带来用户量,还可以提高平台知名度。一个好的秒杀系统,可以提高平台系统的稳定性和公平性,获得更好的用户体验,提升平台的口碑,从而提升秒杀活动的最大价值。
无论哪种中间件的搭建,正常主从模式搭建需要搭建在两台不同的服务器上才是正规的主从搭建模式。因为由于资源的限制,今天来演示一下在同一台服务器上,基于端口不一致搭建Redis的单机主从模式。
作为开发,我们必须熟悉自己所在公司的redis生产集群的部署架构。 主从架构? 集群架构? 用了哪种集群方案? 有没有做高可用保证? 有没有开启持久化机制确保可以进行数据恢复? 线上redis给几个G的内存? 设置了哪些参数? 压测后你们redis集群承载多少QPS?
他面试的时候,身份是某知名公司的小码农一枚,却因为不懂自己生产上Redis是如何部署的,导致面试失败!
大家好,我是捡田螺的小男孩。今天跟小伙伴们一起学习Redis的主从、哨兵、Redis Cluster集群。
现如今 Redis 变得越来越流行,几乎在很多项目中都要被用到,不知道你在使用 Redis 时,有没有思考过,Redis 到底是如何稳定、高性能地提供服务的?
假设我们在一台主从机器上配置了200G内存,但是业务需求是需要500G的时候,主从结构+哨兵可以实现高可用故障切换+冗余备份,但是并不能解决数据容量的问题,用哨兵,redis每个实例也是全量存储,每个redis存储的内容都是完整的数据,浪费内存且有木桶效应。
举例: 例如,假设有一个应用程序叫做"example.exe",它依赖于名为"example.dll"的动态链接库。而"example.exe"在加载"example.dll"时没有使用绝对路径,而是仅仅指定了DLL的名称。攻击者可以将恶意的"example.dll"文件放置在与"example.exe"相同的目录下,当"example.exe"启动时,系统会先在当前目录中查找"example.dll"文件,如果找到,就会加载该文件并执行其中的恶意代码。 DLL劫持可以函数转发劫持也可以往完整DLL插入恶意代码,这里用的函数转发劫持,大致流程如下图所示: https://kiwings.github.io/2019/04/04/th-DLL%E5%8A%AB%E6%8C%81/ 2.2 劫持dbghelp.dll redis-server.exe在执行bgsave时,会先在应用目录查找dbghelp.dll,找不到再去system32目录下找: 而不管redis的权限是Administrator还是普通用户或者Network Service,它对自己的应用目录一定有写文件的权限,我们可以通过Redis的主从复制在应用目录里写入恶意DLL。 2.3 函数转发劫持 对DLL进行函数转发劫持需要导出原本DLL的函数和地址,以保证程序通过恶意DLL调用这些函数时不影响正常功能,DLL的导出函数一般比较多,用Aheadlib之类的工具可以自动化处理。 我这里用的是DLLHijacker,它会自动处理导出表并生成一个VS2019的项目,但这个python脚本有几个bug: https://github.com/kiwings/DLLHijacker (1) VS项目中文乱码: 修复:几个写文件的地方添加 encoding="utf-8"。 (2) 函数导出表有匿名函数的时候,会导致以下报错 [-]Error occur: 'NoneType' object has no attribute 'decode 修复:在几个for循环里添加函数名是否为空的判断可以解决这个问题。 (3) 生成C/C++代码时,没有使用目标DLL的绝对路径,只是用了DLL的名字填充LoadLibrary(),这是一个很严重的bug,会导致函数转发失败、Redis的功能受到影响从而只能劫持一次: 修复:我改成了根据输入的目标DLL路径自动填充。 如果没有使用原DLL的绝对路径,在Process Monitor可以看到,只会调用应用程序目录里的恶意DLL,并没有调用原本的system32下的dbghelp.dll: 从而redis的功能受到影响,导致redis的bgsave只能触发一次DLL调用,第二次bgsave的进程会被阻塞从而无法调用DLL,并且Redis关闭后将无法启动: 这也是网上部分师傅的文章写”不会影响redis运行 但会无法重启“的原因,因为他们也是用的DLLHijacker,并且没有发现有这个坑,这不仅会影响业务,而且只能劫持一次: 正常的DLL劫持不会影响程序的功能,可以劫持很多次,假如我第一次劫持想上线CS但是没有成功,那对面可能不出网,那我可能会再劫持打一个MSF的反向shell,都没成功我也可以继续尝试MSF盲打命令: 正常的DLL转发劫持如下,调用完应用程序目录里的恶意DLL后会调用原DLL: 0x03 漏洞利用 3.1 工具使用 工具下载地址: https://github.com/P4r4d1se/dll_hijack 如是是Windows 64位的Redis DLL劫持的话,可以直接用里面的VS2022版的dbghelp项目。 其他要用我修改后的DllHijacker.py和目标DLL路径生成VS项目: python3 DLLHijacker.py C:\Windows\System32\dbghelp.dll 下载安装VS2022,只用勾C++桌面开发: https://visualstudio.microsoft.com/zh-hans/downloads 打开生成目录里的sln文件,因为原本是VS2019的项目所以会提醒你升级,选确定,不然得另外安装v142的编译组件才能编译VS2019的项目: 打开后在源文件的dllmain.app,修改里面的shellocde就行,其他不用改: 3.2 出网——Cobalt Strike 如果Redis主机直接出网,或者能通其他已经上线CS的出网主机,那直接上CS是最好的选择,CS生成C语言的payload: 源文件的dllmain.app里把payload替换进去,然后选Release x64,生成——生成解决方案: 然后主从复制将dbghelp.dll写过去并bg
1.内存容量有限(redis本身是存储在内存里面,硬件机器本身的内容容量是有限,往redis存储的量可能很大,就会出现内存容量的问题) 2.处理能力有限(一个人干活跟二个人干活的区别。跟内存的限制相似,类似网络不好,能力就收到限制) 3.无法高可用(一旦请求量上去,可能存在系统挂掉,挂掉其他的调用系统就无法调用了)
1.传统数据库遵循 ACID 规则。( A (Atomicity) 原子性,C (Consistency) 一致性,I (Isolation) 独立性,D (Durability) 持久性)2.Nosql 一般为分布式而分布式一般遵循 CAP 定理(一致性(Consistency) (所有节点在同一时间具有相同的数据), 可用性(Availability) (保证每个请求不管成功或者失败都有响应) ,分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作))
笔记内容:redis慢查询日志,php安装redis扩展,redis存储session,redis主从配置 笔记日期:2018-1-03
作为一家数据智能公司,个推不仅拥有海量的关系型数据,也积累了丰富的key-value等非关系型数据资源。个推采用Codis保存大规模的key-value数据,随着公司kv类型数据的不断增加,使用原生的Codis搭建的集群所花费的成本越来越高。
如果有1~2亿条数据需要缓存,那如何设计这个存储案例呢?单机是100%不可能的,肯定得是分布式存储,那具体如和实现呢?
使用过 Redis 的同学应该都知道,它基于键值对(key-value)的内存数据库,所有数据存放在内存中,内存在 Redis 中扮演一个核心角色,所有的操作都是围绕它进行。
以前的redis是单线程模型,其实就是多路复用机制,知道多路复用的来一波6,我们在架构师课程中讲过,那么netty也有,看过老师相关课程的也应该知道。这里不多说了。
2012~2014年,我们的业务开始使用一种新的互联网销售模式——秒杀抢购,一时间,各个产品线开始纷纷加入进来,今天秒杀门票,明天秒杀酒店,等等。各种活动是轮番登场,用户在不亦乐乎地玩着秒杀活动的同时,也对后端技术的支撑提出了一波又一波的挑战。
redis适合放一些频繁使用,比较热的数据,因为是放在内存中,读写速度都非常快,一般会应用在下面一些场景,排行榜、计数器、消息队列推送、好友关注、粉丝。
Redis有两种不同的持久化方式,Redis服务器通过持久化,把Redis内存中持久化到硬盘当中,当Redis宕机时,我们重启Redis服务器时,可以由RDB文件或AOF文件恢复内存中的数据。
Redis Cluster是Redis的分布式解决方案,在3.0版本正式推出,解决单master架构的内存、并发、流量等瓶颈,以达到负载均衡的目的。
redis 的复制分为两部分操作 同步(SYNC)和 命令传播(command propagate)
大家好,我是老田,前面我们已经分享了五篇连环炮文章,今天我们继续。今天我们接着来聊聊Redis。Redis已经成为我们开发者必备技能之一了,同时面试也是必问的。下面就来对Redis进行一个总结,然后赠送47连环炮。
Twemproxy 又称nutcracker ,是一个memcache、Redis协议的轻量级代理,一个用于sharding 的中间件。有了Twemproxy,客户端不直接访问Redis服务器,而是通过twemproxy 代理中间件间接访问。 Twemproxy 为 Twitter 开源产品,简单来说,Twemproxy是Twitter开发的一个redis代理proxy,类似于nginx的反向代理或者mysql的代理工具,如amoeba。Twemproxy通过引入一个代理层,可以将其后端的多台Redis或M
1、主库的used_memory_peak_human达到60.97G,实际上主库的maxmemory只配置了32G
在服务开发中,单机都会存在单点故障的问题,及服务部署在一台服务器上,一旦服务器宕机服务就不可用,所以为了让服务高可用,分布式服务就出现了,将同一服务部署到多台机器上,即使其中几台服务器宕机,只要有一台服务器可用服务就可用。
在如今的业务场景下,高可用性要求越来越高,核心业务跨可用区已然成为标配。腾讯云数据库高级工程师刘家文结合腾讯云数据库的内核实战经验,给大家分享Redis是如何实现多可用区,内容包含Redis主从版、集群版原生架构,腾讯云Redis集群模式主从版、多AZ架构实现以及多AZ关键技术点,具体可分为以下四个部分: 第一部分:介绍Redis的原生架构,包含主从版及集群版; 第二部分:介绍腾讯云Redis架构,为了解决主从架构存在的问题,腾讯云使用了集群模式的主从版。其次为了更好的适应云上的Redis架构,引入了Pro
说明:个人原创,本人在一线互联网大厂维护着几千套集群,关于redis使用的一些坑进行了经验总结,希望能给大家带来一些帮助
会导致缓冲区需越来越多内存暂存数据。当缓冲区占用内存>设定上限阈值,就会出现缓冲区溢出。发生溢出,就会丢数据。不给缓冲区设上限,不就没这问题了?No!随累积数据增多,缓冲区所占内存空间越大,耗尽Redis机器可用内存时,Redis实例就会崩溃!
虽然 reuse port 是在 linux 3.9 才被合并进来,但有 backport 到更早之前的版本(至少我们在使用的 2.6.32 是有的),很多博客在这点上有些误导。另外,在 reload 时候也不能简单将老的监听关闭,会导致 tcp backlog 里面这些三次握手成功但未 accept 的连接丢失,业务在这些连接上发送数据则会收到 rst 包。
在上一篇博客我们介绍了------Redis哨兵(Sentinel)模式,哨兵模式主要是解决高可用问题,在master节点宕机时,slave节点能够自动切换成为master节点
Redis应该算面试中必问的一个知识点,但是发现很多童鞋并不熟悉这块,这篇就常见的一些问题做一些整理,有不对的地方欢迎留言指正!
今年疫情带来的挑战很明显,远程办公和在线教育用户暴涨,从1月29到2月6日,日均扩容1.5w台主机。业务7×24小时不间断服务,远程办公和在线教育要求不能停服,停服一分钟都会影响成百上千万人的学习和工作,所以这一块业务对于我们的要求非常高。
领取专属 10元无门槛券
手把手带您无忧上云