• [技术干货] Redis数据库数据类型解释
    Redis 内存数据库可以存储键与5种不同数据类型之间的映射,这 5种数据类型分别为 STRING(字符串)、HASH(散列)LIST(列表)、SET(集合)和 sorted SET(有序集合)。结构类型结构存储的值结构的读写能力STRING  可以是字符串、整数或者浮点数  对整个字符串或者字符串的其中一部分执行操作;对整数和浮点数执行自增(increment)或者自减(decrement)操作HASH 包含键值对的无序散列表 添加、获取、移除单个键值对;获取所有键值对LIST一个链表,链表上的每个节点都包含了一个字符串从链表的两端推入或者弹出元素;根据偏移量对链表进行修剪(trim):读取单个或者多个元素:根据值查找或者移除元素SET包含字符串的无序收集器(unordered collection),并且被包含的每个字符串都是独一无二、各不相同的添加、获取、移除单个元素:检查一个元素是否存在于集合中;计算交集、并集、差集;从集合里面随机获取元素sorted SET字符串成员(member)与浮点数分值(score)之间的有序映射,元素的排列顺序由分值的大小决定添加、获取、删除单个元素;根据分值范围(range)或者成员来获取元素
  • [技术干货] 华为云DCS社区版Redis6.0技术大揭秘
    自从Redis进入6.0版本之后,新特性和功能改进每月都有新变化,升级速度简直是开挂上天啦!并且,对于 6.0 版本,Redis 之父 Antirez 在 RC1 版本发布时(2019-12-19)在他的博客上连续用了几个“EST”词语来评价:这个版本提供了诸多令人心动的新特性及功能改进,比如新网络协议 RESP3,新的集群代理,ACL 等,其中关注度最高的应该是“多线程”了。华为云DCS也第一时间启动了对Redis 6.0的支持工作,经过大量前期工作筹备,华为云DCS社区版 Redis 6.0已于2021年8月初发布,正在公测 。同时,与开源Redis6.x相比,DCS 社区版Redis6却是开源版本性能的1.5~3倍。那它是如何做到的呢?下面来给大家展开聊聊。DCS 社区版 Redis6.0 产品性能话不多说,先上图:1、性能对比测试如图,在400客户端连接情况下,2线程时,DCS写性能是开源的1.68倍,读性能是开源的1.54倍,时延分别比开源快39%和35%;4线程时,DCS写性能是开源的2.56倍,读性能是开源的2.22倍;时延分别比开源快61%和55%。2、性能提升剖析看官们可以看到DCS 社区版Redis 6.0版本性能有了大幅提升,那它具体是怎么做到的呢?听小哥慢慢道来。在 Redis 的多线程方案中,I/O 线程任务仅仅是通过 Socket 读取客户端请求命令并解析,却没有真正去执行命令,所有客户端命令最后还需要回到主线程去执行,因此对多核的利用率并不算高,而且每次主线程都必须在分配完任务之后忙轮询等待所有 I/O 线程完成任务之后才能继续执行其他逻辑。Redis之所以如此设计它的多线程网络模型,我认为主要的原因是为了保持兼容性,又能利用多核提升 I/O 性能,应该是一个折中的选择。华为云DCS Redis实现了真正的多线程优化提升,除了多线程网络并发,还优化了多线程事件处理机制,使我们的资源利用率和性能收益提升2~3倍。除此之外,垂直弹性伸缩也能更多层次等等。3、与开源版本深入对比下表是DCS社区版Redis 6.0与开源版本的详细对比:综上:华为云DCS Redis 6.0社区版带来了极致性能、功能全面、可靠性强、性价比高的云服务,并且完全兼容开源Redis,客户端无需修改代码,开通后即可使用,使企业完全无需后顾之忧就能享受到业务响应速度数倍提升的黄金收益。【小喇叭】:看官们,现在DCS Redis 6.0 社区版正在上线公测 ,期待大家踊跃报名,数量有限,先到先得。参考、致谢:• Redis 作者 Antirez 的博客:http://antirez.com• https://mp.weixin.qq.com/s/SkYNjypPY3iW-DH01yYAiw• https://segmentfault.com/a/1190000039223696
  • [赋能学习] 华为FusionInsight MRS实战 - 使用FlinkSQL处理数据并使用redis做实时展示
    # 华为FusionInsight MRS实战 - 使用FlinkSQL处理数据并使用redis做实时展示## 场景说明【需求】计算最近1小时各个账户交易总金额。【分析】将账户交易数据接入Kafka中,通过Flink计算过去1小时各个账户的交易总金额,将计算结果写入Redis中。做实时大屏展示。【实现】通过FlinkSQL的滚动窗口计算数据流图![20210911_164352_35.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202109/11/164525sv8902mubn5u1of3.png)## 操作步骤- 登录华为FusionInisght MRS Flink WebUI![20210908_115504_73.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202109/11/164547s0x2mzir5r7m079i.png)- 在作业管理选择新建作业创建一个FlinkSQL任务 ![20210911_163554_74.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202109/11/164608rfvxy2tr9jhjzj3i.png)- 编辑如下Flink SQL语句```CREATE TABLE kafka_source ( account varchar(10), cost int, ts AS PROCTIME()) WITH ( 'connector' = 'kafka', 'topic' = 'redisdemo', 'properties.bootstrap.servers' = '172.16.9.117:21005', 'properties.group.id' = 'testGroup', 'scan.startup.mode' = 'latest-offset', 'format' = 'json');CREATE SINK STREAM redis_sink(account varchar,costs int,PRIMARY KEY(account)) WITH ( 'isSafeMode' = 'true', 'clusterAddress' = '172.16.9.117:22404,172.16.9.118:22404,172.16.9.113:22404', 'redistype' = 'String', 'type' = 'Redis', 'isSSLMode' = 'false');INSERT INTO redis_sinkSELECT account, SUM(cost)FROM kafka_sourceGROUP BY TUMBLE(ts, INTERVAL '10' SECOND), --为了快算看到计算结果使用10s窗口 account;```- 点击语义校验,确保语义校验通过 ![20210911_164805_29.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202109/11/164950casmatpxvg9aliuy.png)- 启动该Flink SQL任务 ![20210911_164823_27.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202109/11/165010yzfgzaks191n3vik.png)- 使用kafka客户端插入测试数据 ``` {"account": "A1","cost":"11"} {"account": "A1","cost":"22"} {"account": "A2","cost":"33"} {"account": "A3","cost":"44"} ``` ![20210911_163947_19.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202109/11/164638glckh5mcnpxxiphf.png) 注意: 因为flink窗口时间为10秒,并且redis是key value数据库,数据会根据主键覆盖,所以需要在10s内将数据全部输入- 登录redis客户端查看结果: `redis-cli -c -h 172.16.9.117 -p 22404` ![20210911_164146_38.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202109/11/1646585kpw2itg0fsmmwbq.png)
  • [公告] 为什么选择混合云架构?(下)
    在共享数据加速,保持数据(如订单数据)一致性的场景下,采用单主多从的缓存模式,在两个数据中心更新缓存时,是先写到一个Redis Master集群中,然后从一个Redis Master集群同步到两个数据中心的Redis Slave集群中,整个请求的逻辑就是:请求进入其中一个机房的微服务中,微服务首先会读取微服务本地的一级缓存,如果没有命中,再去本数据中心的Redis Slave集群进行查询,如果还是没有命中,再回源到本数据中心的数据库中进行查询,将读取后的数据写入到Redis Master集群,同时更新本地的一级缓存和Redis Slave集群,当然Redis Master集群也会将数据同步更新到另一个数据中心的Redis Slave集群中。这种单写多读的缓存模式实现数据加速以及保证数据一致性的要求。目前这种跨机房的主从同步延时并不明显,延迟在一两毫秒左右。在共享数据加速但不考虑数据(商品)一致性的场景下,也是采用多活的理念,即在两个数据中心部署完全对等的缓存集群。在上图的机房一中,当有数据请求时,首先从本地一级缓存进行查询,如果没有命中,再去查本地的Redis集群,依旧没有命中时,回源到本地的数据库进行查询,同时将查询到的数据更新到本数据中心的Redis集群。虽然两个数据中心的缓存集群部署一致,但是在Redis集群中存的数据可能不一致。数据层作为六层架构中的最底层,主要的应用还是基于MySQL的主从模式。下面提到的特点是在非核心业务上的一些尝试,并没有大面积应用:同城双活,即由业务层来控制数据的实时性和最终一致性,而不是通过数据同步来保证实时性和一致性。业务层双写,数据异步分发至两个数据中心,任意机房写入的数据通过异步消息的方式分发到另一个机房,以此来保证两个机房数据的最终一致性。业务层通过二级查询保证数据的实时一致性,由于业务层双写只能保证数据的最终一致性,无法保证实时一致性,因此,针对具有实时一致性要求的业务场景,我们通过业务层的二级查询来保证。 重复写入应对单机房故障,当任意机房出现故障时,如果写入的数据还没有分发至另一个机房,则由业务层在可用机房重复写入数据,通过算法来生成相同的ID。通过failover库为高可用提供双重保险,针对流水型业务数据,在数据库故障时,需要进行主从切换,此时通过业务层将所有数据的读写切换至failover库,主库恢复以后再将流量切回主库。垂直拆分与水平拆分结合使用。 服务化 之所以需要服务化,是因为在做服务化之前系统高度耦合,牵一发而动全身,直接影响到系统可用性;同时业务相互影响,系统很难维护;系统逻辑过于耦合,很难进行水平扩展;也无法通过流控、降级等手段保障系统的可用性;此外由于系统的高度耦合,极易产生雪崩效应。因此基于上述原因,服务化改造势在必行。对于服务化而言,最核心的就是服务的发现、注册、调用。目前有货采用的是Spring+Register+Zookeeper搭建的最简单的服务框架,通过Zookeeper完成的服务注册和发现,通过Register完成服务的调用。集中式的LoadBalance,在服务消费者和提供者之间通过阿里云的负载均衡或者F5搭建独立的LoadBalance,通过集中式的负载均衡设备完成对服务调用的负载均衡;在进程内做负载均衡,即软负载的方式,将负载均衡策略渗入到服务框架里面,服务消费者作为负载均衡的客户端,请求只需要从服务注册中心获取最新的服务列表,利用服务框架自身携带的负载均衡策略,完成负载均衡的调用。在服务降级方面,通过使用开源的Hystrix配置服务超时时间,当服务调用超时时,直接返回或执行Fallback逻辑。另外基于Hystrix提供的熔断器组件,可以自动运行或手动调用对当前服务进行暂停后再重新调用服务。流量控制方面,通过计数器服务限定单位时间内当前服务的最大调用次数(比如600次/分钟),如果超过则拒绝,以保证系统的可用性;同时为每个服务提供一个小的线程池,如果线程池已满,调用将被立即拒绝,默认不采用排队,加速失败判定时间。服务化中,对于服务的监控、性能优化以及调用链的分析也尤为重要。通过Hystrix提供的服务化监控工具实时观察在线服务的运行状态,有了监控之后可以进行相应的性能优化。对于调用链分析,当请求从网关层进入时,追加一个Trace ID,Trace ID会在整个调用过程中保留,最后通过分析Trace ID将整个请求的调用链串联起来。
  • [新手课堂] 集群如何同步会话状态?
    利用 Redis 同步 session Redis 可以做分布式,正式因为这个功能他才可以用来做 session 同步。他可以把 web 服务器中的内存组合起来,形成一个“内存池”,不管是哪个服务器产生的 session 都可以存放于这个内存池中,其它的都可以使用。 以这种方式来同步 session,不会加大数据库的负担,安全性比 cookie 要大大提高,把 session放到内存中,这样比从文件读取也要快很多。
  • [技术干货] Redis数据库的主要应用场景
    Redis提供了灵活多变的数据结构和数据操作,主要应用于如下场景: 最新列表。Redis 列表结构,LPUSH 可以在列表头部插入一个内容 ID 作为关键字,LTRIM 可用来限制列表的数量,这样列表就永远为N个ID,无需查询最新的列表,直接根据 ID 去到对应的内容页即可。常见的取最新N个数据的操作,比如典型的取某网站的最新文章。 排行榜应用。很多网站应用都有排行榜应用,如华为商城的月度销量榜单、商品按时间的上新排行榜等。Redis 提供的有序集合数据类型能实现各种复杂的排行榜应用。这个场景与上面场景的不同之处在于,前面操作以时间为权重,这个是以某个条件为权重,比如按“顶”的次数排序。 分布式会话。当在相对复杂的多应用系统中,一般都会搭建以 Redis 等内存数据库为中心的 session 服务,session 不再由容器管理,而是由 session 服务及内存数据库管理。比如,需要精准设定过期时间的应用,如用户会话信息。 计数器应用。计数器,就是记录电商网站商品的浏览量、用户访问网站次数、视频网站视频的播放次数等统计信息。为了保证数据实效性,每次浏览都需加 1,并发量高时如果每次都请求数据库操作无疑是种挑战和压力。Redis 提供的 incr 命令来实现计数器功能,通过内存操作,性能效果都非常好,非常适用于这些计数场景。 构建队列系统,例如消息队列。 缓存。缓存现在几乎是所有中大型网站都在用的必杀技,合理的利用缓存不仅能够提升网站访问速度,还能大大降低数据库的压力。常见如缓存关系数据库中的频繁访问的表数据。 发布/订阅功能, pub/sub。 手机验证码,使用expire设置验证码失效时间。 分布式锁。在很多互联网公司中都使用了分布式技术,分布式技术带来的技术挑战是对同一个资源的并发访问,如全局ID、减库存、秒杀等场景,并发量不大的场景可以使用数据库的悲观锁、乐观锁来实现,但在并发量高的场合中,利用数据库锁来控制资源的并发访问是不太理想的,大大影响了数据库的性能。可以利用 Redis 的 SETNX 功能来编写分布式的锁,如果设置返回1说明获取锁成功,否则获取锁失败,当然实际应用中有更多的方面需要考虑。 社交网络。点赞、踩、关注/被关注、共同好友等是社交网站的基本功能,社交网站的访问量通常来说比较大,而且传统的关系数据库类型不适合存储这种类型的数据,Redis 提供的哈希、集合等数据结构能很方便的实现这些功能。
  • [交流吐槽] Redis提供6种数据淘汰策略
    volatile-lru:从已设置过期时间的数据集(server.db.expires)中挑选最近最少使用的数据淘汰volatile-ttl:从已设置过期时间的数据集(server.db.expires)中挑选将要过期的数据淘汰volatile-random:从已设置过期时间的数据集(server.db.expires)中任意选择数据淘汰allkeys-lru:从数据集(server.db.dict)中挑选最近最少使用的数据淘汰allkeys-random:从数据集(server.db.dict)中任意选择数据淘汰no-enviction(驱逐):禁止驱逐数据
  • [公告] 混合云模式架构设计
    项目背景:用户通过域名访问vip, nginx做为负载均衡为后端应用分发请求, 后端应用为dubbo服务,存储分为redis和mysql. redis做为持久会存储数据库,支持前端业力. 并且通过mq同步数据到mysql,供后端使用. 同时后台写mysql也要通过mq同步到redis.目前后端服务qps最高可以达到5万,本次架构设计在不重构的情况下短期内最快的方法达到目标10万qps.架构方案:一,现有idc架构可支撑5万qps。这是经过一年考验下来的,可做为保底的;如果应用全部上云,需要从0开始重新验证能否达到现有5万qps,再去验证能否达到10万qps,时间等未知风验很大;  二,10万qps目标,建议用简单粗暴的方式,直接把idc应用层架构复制一套上云;不建议在现有架构上继续调优,现在架构如果不重构,可能很难找到问题;与其这样不如把人力时间用到另一个方向,比如数据中心;   三,由idc+公有云两套系统构成混合云模式,数据统一使用idc的redis和mysql,公有云与idc 的数据库连接建立专线;混合云的方式可以检测公有云的实际性能,也能为将来全部迁移公有云提供真实参考;   四,平时比赛,使用idc架构完全可以支撑,公有云留少量机器和用户请求预热,重要比赛,临时增加云资源扛突发,服务器成本节约,扩展性也灵活;   五,公有云都有出现过大规模事故,造成全站不能访问的情况,为了保险,我们依然要保留idc的服务,所以混合云也许是最适合的;      技术难点:   一,如何将用户请求分流到 idc和公有云两套应用   1,域名解析两条A记录,分别指向idc和公有云两个vip,通过dns平均分配用户请求   2,idc架构在nginx前端增加四层负载均衡(lvs,ha_porxy),由四层负载均衡将用户请求转发给idc的nginx和公有云的负载均衡,lvs与公有云通信通过专线;   二,前端应用入口放大,后端数据中心,需要扩容   1,redis使用多主多从,redis3.0 还是用 代理(predixy,codis);   2,业务拆分,组建更多的一主多从;      具体实施:   1,双系统流量分发配置lvs即可,本赛季最好能用上几轮,演练资源增减,熟悉流程,检测可行性;   2,redis数据中心需要大量的测试,选型,可做重点研究(这也是目前急需解决的单点);
  • [技术干货] 【云图说】第223期 初识云数据库GaussDB(for Redis)
    云数据库GaussDB(for Redis)介绍页入口,详情请点击链接云数据库GaussDB(for Redis)成长地图入口,详情请点击链接小云妹又来啦,生命不息,学习不止,今天要着重介绍的是我们的——云数据库GaussDB(for Redis)有着稳定、可靠的企业级产品定位,它完全兼容开源Redis,还能为企业带来降本增效的重要价值。稳定实用就是我~~~
  • [技术干货] Redis数据导出与持久化
    企业级Redis的几个典型需求:海量数据存储、高并发、服务高可用、数据高可靠Redis数据存储在内存中,服务器集群的内存已能达到T级别,能实现每秒几十万上百万级别的高并发。那么Redis如何实现数据高可靠呢?Redis不同于磁盘数据库,服务器宕机或者Redis服务关闭都会导致内存中数据丢失。因此引入Redis的持久化机制,实现灾备,数据恢复,以及服务高可用能力:借助持久化文件的增量同步,实现Redis主备高可用。将持久化文件转移存储,实现异地灾备与数据恢复能力下面简要介绍下Redis数据导出与持久化&远程导出很多场景下,我们需要将远程的Redis数据导出到本地。主要利用了Redis的持久化命令(SAVE/BGSAVE),以及复制命令(SYNC/PSYNC)导出方式1: Redis-liRedis自带命令行工具,它支持导出RDB文件,也支持将持久化的AOF文件整库导入。导出为RDB文件命令:redis-cli -h {redis_address) -p 6379 --rdb {outputfile.rdb}开启AOF持久化命令:redis-cli -h {redis_address) -p 6379 config set appendonly yes注意:此命令会生成一个AOF文件,默认保存在Redis实例运行的安装目录导出方式2: 第三方开源工具redis-portredis-port的导出工作原理,主要是伪装成slave,利用sync命令接收RDB文件。导出为RDB文件命令:redis-dump -n 3 -m {password}@{redis-host}:{port} -o {outputfile. rdb}导出方式3:有些云厂商服务禁用了客户端发起的config/save/sync等命令,导致不能使用redis-cli或第三方工具导出RDB、 AOF文件。不过云厂商一般都提供Redis实例的备份以及备份文件下载功能。下载文件为AOF或RDB格式。
  • [交流吐槽] Redis 常见的性能问题
    主服务器写内存快照,会阻塞主线程的工作,当快照比较大时对性能影响是非常大的,会间断性暂停服务,所以主服务器最好不要写内存快照。Redis 主从复制的性能问题,为了主从复制的速度和连接的稳定性,主从库最好在同一个局域网内。
  • [交流吐槽] Redis 淘汰策略
    volatile-lru:从已设置过期时间的数据集(server. db. expires)中挑选最近最少使用的数据淘汰。    volatile-ttl:从已设置过期时间的数据集(server. db. expires)中挑选将要过期的数据淘汰。    volatile-random:从已设置过期时间的数据集(server. db. expires)中任意选择数据淘汰。    allkeys-lru:从数据集(server. db. dict)中挑选最近最少使用的数据淘汰。    allkeys-random:从数据集(server. db. dict)中任意选择数据淘汰。    no-enviction(驱逐):禁止驱逐数据。
  • [交流吐槽] Redis 如何做内存优化
     尽量使用 Redis 的散列表,把相关的信息放到散列表里面存储,而不是把每个字段单独存储,这样可以有效的减少内存使用。比如将 Web 系统的用户对象,应该放到散列表里面再整体存储到 Redis,而不是把用户的姓名、年龄、密码、邮箱等字段分别设置 key 进行存储。
  • [交流吐槽] Redis 分布式锁有什么缺陷
    Redis 分布式锁不能解决超时的问题,分布式锁有一个超时时间,程序的执行如果超出了锁的超时时间就会出现问题。
  • [技术干货] Redis 怎么实现分布式锁
    Redis 分布式锁其实就是在系统里面占一个“坑”,其他程序也要占“坑”的时候,占用成功了就可以继续执行,失败了就只能放弃或稍后重试。占坑一般使用 setnx(set if not exists)指令,只允许被一个程序占有,使用完调用 del 释放锁。
总条数:222 到第
上滑加载中