rdb

为了部署有状态服务，单独给k8s部署了一套ceph块存储集群，本文记录了k8s集群对接外部ceph集群的方案和问题。期间，还是遇见不少坑，好在都解决了。 环境准备 我们使用的k8s和ceph环境见： https://blog.51cto.com/leejia/2495558 https://blog.51cto.com/leejia/2499684 静态持久卷 每次需要使用存储空间，需要存储管理员先手动在存储上创建好对应的image，然后k8s才能使用。 创建ceph secret 需要给k8s添加一个访问ceph的secret，主要用于k8s来给rbd做map。 1，在ceph master节点执行如下命令获取admin的经过base64编码的key（生产环境可以创建一个给k8s使用的专门用户）： # ceph auth get-key client.admin | base64 QVFCd3BOQmVNMCs5RXhBQWx3aVc3blpXTmh2ZjBFMUtQSHUxbWc9PQ== 2，在k8s通过manifest创建secret # vim ceph-secret.yaml apiVersion: v1 kind: Secret metadata: name: ceph-secret data: key:

1.利用Redis缓存实现商品分类查询 1.1 编辑ItemCatController @RequestMapping ( "/list" ) public List < EasyUITree > findItemCatList ( Long id ) { Long parentId = ( id == null ? 0 L : id ) ; //根据parentId=0 查询一级商品分类信息 //Long parentId = 0L; //return itemCatService.findItemCatListByParentId(parentId); //版本号 1.0.2 调用次方法 开发人员为xxxx return itemCatService . findItemCatCache ( parentId ) ; } 1.2 编辑ItemCatService package com . jt . service ; @Override public List < EasyUITree > findItemCatListByParentId ( Long parentId ) { QueryWrapper < ItemCat > queryWrapper = new QueryWrapper < > ( ) ; queryWrapper . eq ( "parent_id"

可以先想一下自己的部门或项目组是否面临这些问题： 1. 投入很多技术力量做报表，却还是疲于应付 2. 用了高端报表工具和敏捷 BI，却还是不够用 3. 技术高手用来做报表，感觉很浪费 4. 对于频繁多变的报表需求，需要低成本应对方案 专门用于统计分析的报表业务有一个特点，就是业务稳定性非常差。在业务开展过程中会催生很多新的查询需求，而且已实现的查询需求还会经常变化，这就造成了没完没了的报表。所以经常会有这么一段对话 报表没完没了是需求使然，无法规避，只能适应，而目前主要的是问题是普遍缺少一种低成本的方案来适应没完没了的报表。 为什么报表开发成本一直居高不下？ 我们知道，报表工具的主要作用是将报表呈现阶段的开发工具化，使用报表工具可以将原本需要硬编码的工作通过工具来提高生产效率；但报表开发的另一个阶段：数据准备，却仍然在使用原始的硬编码方式处理，有时我们要编写非常复杂的 SQL、存储过程和 JAVA 程序，这样的工作通常要依赖高水平的技术人员才能完成。 另外，采用过于原始手段会带来报表维护困难，复杂的代码无论从编写还是修改都比较困难，这样又会加剧报表开发成本居高不下！ 除了技术原因外，还有应用结构和团队管理方面的因素也会造成报表开发的成本居高不下。在许多应用系统中，报表是耦合在其中的一些功能，而业务系统的技术环境很复杂，这就迫使报表开发人员也要熟悉这些东西

关系数据库的应用已经有了半个世纪的历史，其各种子类别(如文档、键值数据库和缓存数据库)是IT领域中长期存在的部分。很多人可能会认为数据库创新的时代已经过去了。但是，云计算基础设施和服务的兴起为这个原本停滞不前的市场注入了新的活力。 主要的云计算提供商最初将数据库作为应用程序使用，以便在通用计算实例上运行，但很快就开始使用更高级别的应用程序服务来扩展其IaaS产品。云计算数据库已经成为技术开发的关键领域，云计算提供商可以通过启动不同类型的数据库来满足业务需求来进行竞争。 1. 了解市场 调研机构Gartner公司认为，云计算是数据库市场的未来。该公司预测，到2022年，将有75%的数据库部署在云中。这一数字基于客户对新应用程序和现有应用程序的查询和访问，这些应用程序正在以越来越快的速度向云端迁移，预计这一趋势将会加速。 例如，在Gartner公司发布的2019年数据库市场份额排名中，AWS公司排名第三，高于2013年的第七位。事实上，AWS公司数据库分析师收到大部分查询信息都与云平台有关。而且，由于托管公共云服务的弹性、可扩展性以及按需性质，在云中进行的创新可能无法在内部部署复制。 此外，Gartner公司估计，2018年云计算数据库收入占整体数据库软件和服务收入增长的68%，其中AWS和Microsoft的收入占到绝大部分。 2. 熟悉数据库选项 为了规划这个以云计算为中心的未来

一、定义 AOF是将所有的Redis的写命令记录到文件中，这个文件叫做AOF文件。 二、开启 ############################## APPEND ONLY MODE ############################### appendonly yes #默认的是no #是否开启 appendfilename "appendonly.aof" #文件名称 # appendfsync always appendfsync everysec #表示每秒执行一次fsync # appendfsync no 三、同时开启 RDB与AOF同时开启，优先加载AOF的文件。 四、AOF重写 用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。 五、优缺点 优点：AOF提供了每秒同步得机制，所以丢失的数据最多是1秒内的数据。 缺点：相同的文件，AOF的文件要比RDB文件大一点。而且速度要比RDB慢一点 刻意练习 AOF的优缺点是什么 参考： Redis详解（七）------ AOF 持久化 来源： oschina 链接： https://my.oschina.net/u/4407552/blog/4279419

迁移工具：redis-shake ，版本：v1.6.28 使用参考： https://help.aliyun.com/knowledge_detail/111066.html 校验工具：redis-full-check 版本1.4.8 使用参考： https://help.aliyun.com/document_detail/116887.html?spm=a2c4g.11186623.2.16.2d245d3eAoHLGq#concept-221787 源redis cluster 版本3.2.0，目标redis cluster 版本3.2.0 [STG-rmytest01_C00:rd01:5717:M ~]$./redis-shake.linux -conf=redis-shake.conf -type=sync 测试步骤与配置信息 [STG-rmytest01_C00:rd01:5717:M ~]$cat redis-shake.conf #conf.version = 1 id = redis-shake log.file =/u/redis/home/redis/hzy/redis-shake-v1.6.28/redis-shake.log log.level = info pid_path =/u/redis/home/redis/hzy/redis-shake-v1

搭建环境 系统： centos 7.4 服务器金山云 安装ruby环境 [root@jsy-bj-test00 ~]# yum install -y ruby rubygems 复制6份redis服务 [work@jsy-bj-test00 ~]$ cp -rp redis redis1 [work@jsy-bj-test00 ~]$ cp -rp redis redis2 [work@jsy-bj-test00 ~]$ cp -rp redis redis3 redis配置文件修改 #六个节点需做如下更改 [work@jsy-bj-test00 ~]$ vim redis1/etc/redis.conf [work@jsy-bj-test00 ~]$ sed -i 's/port 6379/port 6380/g' redis5/etc/redis.conf #修改端口 port 6380 #打开注释，开启集群模式 cluster-enabled yes #集群的配置文件 cluster-config-file nodes-6380.conf [work@jsy-bj-test00 ~]$ sed -i 's/cluster-config-file nodes-6379.conf/cluster-config-file nodes-6380.conf/g' redis5/etc

最近一段时间与redis接触比较频繁。发现有些东西还是工作中经常会用到的，自己也花了点时间巩固下。本篇文章主要是以总结性的方式梳理，因为redis的主题很大，任何一个技术点展开都是几篇文章的量。也可以说这篇文章是个概览。 1.redis基本数据结构与短结构压缩 了解redis的数据结构有助于了解每种数据结构的优劣势，方便设计合理的cache结构。 1.1.redis提供5种数据结构 1.STRING：可以存储字符串、浮点型、整型，如果是字符串可以执行字符串操作，如果是浮点型、整型也可以执行加减操作。redis会识别出它的具体类型。 2.LIST：链表，链表中的每个NODE包含一个字符串。可以对链表进行两端推入、弹出操作。 3.SET：无序集合，不会存在相同的集合元素，集合的交集、并集、差集运算。 4.HASH：键值对的无需散列，增、删、获取键值。 5.ZSET：有序集合，根据一个浮点数分值来排序。 这几种数据类型用起来场景还是比较明显的，遇到复杂的cache场景我们需要结合这几种数据结构一起来设计。 比如，购物车场景，我们首先需要两个HASH来存储，第一个HASH是用户与购物车之间的关系，第二个HASH是购物车中的商品列表。 先通过userId获取到shoppingCartId，然后再通过shoppingCartId就可以获取到用户购物车的ProductIds

redis 持久化机制有两种：RDB 和 AOF。 RDB RDB 机制是对 redis 中的数据执行周期性的持久化。每个几分钟、几小时、几天生成 redis 内存中的数据的一份完整的快照。 AOF 每条写入命令作为日志，写入 aof 文件中。现代操作系统中，写入文件不是直接写磁盘，会先写到 os cache，然后到一定时间再从 os cache 到磁盘文件。每隔 1 秒调用一次操作系统的 fsync 操作，强制将 os cache 中的数据，刷入磁盘文件中。 为了保证性能，会先写入 os cache 中，然后定期强制执行 fsync 操作将数据刷入磁盘。 原理： 每台单机 redis 的数据量收到内存限制，所以 aof 不会无线增长； 当数据超过内存限制的时候，会自动使用 LRU 算法将数据淘汰掉； AOF 存放的是每条写入的命令，所以会不断的膨胀，当达到一定的时候，会做 rewrite 操作； rewrite 操作：基于当时 redis 的内存中的数据，重新构造一个更小的 aof 文件，然后删除旧的 aof 文件。 总结：aof 被不断的追加，内存中的数据有最大限制，会被自动淘汰，当 aof 中的数据大于内存中数据时，就会执行 rewrite 操作，生成新的 aof 文件。 AOF 机制对每一条写入命令作为日志，以 append-only 的模式写入一个日志文件中，在

1. 从节点 连接 主节点 ，发送psync?-1命令； 2.主节点发现从节点是第一次复制，返回 FULLRESYNC {runId} {offset} 3. 从节点接收主节点信息后，保存到 info 中。 4. 主节点在发送 FULLRESYNC 后，启动 bgsave 命令，生成 RDB 文件（数据持久化）。 5.并使用缓冲区记录此后执行的所有写命令； 6. 从节点 收到快照文件后丢弃所有旧数据，载入收到的快照； 7.主节点 快照发送完毕后开始向从 节点 发送缓冲区中的写命令； 8. 从节点 完 成对快照的载入，开始接收命令请求，并执行来自主节点缓冲区的写命令； 来源： oschina 链接： https://my.oschina.net/u/4167465/blog/4492362