![](https://img-blog.csdnimg.cn/20201014180756916.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
数据库
文章平均质量分 89
jeff-y
所有文章用于个人记录,仅供参考,有错误的地方还请指出错误。
展开
-
redis集群-----切片集群(cluster)
背景上篇文章聊到了redis的哨兵机制,哨兵的作用是保证主从节点宕机或者故障的时候可以可以进行自愈,选举合适的master并且告知client。这个机制也就保证了redis集群的可用性。但是这次我们又遇到了新问题,那就是主从复制架构的情况下redis 的内存不够用了该怎么办。有人说那就不断的阔各个机器的内存,按照常理我们都知道一个人的力量是有限的。当一个节点的内存过大,那么我们在进行同步的时候会通过RDB文件进行同步,而生成rdb文件是通过fork一个子进程进行的(下篇文章我们仔细聊下这个过程),在进行原创 2022-03-21 00:20:57 · 1680 阅读 · 0 评论 -
Redis集群架构----主从复制
上次我们看了CAP定理,以及CP,AP架构的原则,这篇文章主要聊下redis的几种集群架构方式。以及对应的架构原则。主从理解对于任何一个服务我们都在讲高可用,如果对于一个单机服务如果挂掉了那岂不是就GG了。那我们为了让服务available那就进行多起几个服务进行数据冗余,达到挂掉一个还有一个顶着。但是在保存的数据的时候会有很多的麻烦事,写数据的一致性问题,当给每台机器都进行写数据的时候且各个节点之间的数据是互相同步的,这个时候就遇到了并发安全问题,通过各种加锁同步操作会对整个服务的性能严重下降,这也就原创 2022-03-13 18:34:23 · 4539 阅读 · 0 评论 -
JedisPool资源池优化
JedisPool资源池优化合理的JedisPool资源池参数设置能够有效地提升Redis性能。本文档将对JedisPool的使用和资源池的参数进行详细说明,并提供优化配置的建议。使用方法以Jedis 2.9.0为例,其Maven依赖如下:<dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> <version&g原创 2021-09-23 23:15:30 · 420 阅读 · 0 评论 -
ClickHouse学习-建表和索引的优化点(一)
ClickHouse 优化点clickhouse 相对于mysql,除了在mysql在SQL和索引的优化空间比较大外,而其他的clickhouse的优化空间还是很大的,对于clickhouse他的服务端配置参数对于任务的影响还是很大的。现在我们来看看clickhouse都有哪些常规的优化点,今天主要学习一下创建表的时候需要注意的点建表优化1. 数据类型1.1 null值尽量避免关于NULL存储的问题,尽量不要制定为nullable 这样会影响列的查询性能,因为如果有null值对于clickh原创 2021-08-29 01:36:35 · 6088 阅读 · 0 评论 -
clickhouse表引擎megerTree
clickhouse 表引擎官方文档:https://clickhouse.tech/docs/zh/engines/table-engines/mergetree-family/mergetree/#choosing-a-primary-key-that-differs-from-the-sorting-keyclickhouse是一个列式存储的应用于OLAP场景的数据库管理系统。数据库管理系统分为:客户端底层存储的表引擎。包括我们所熟悉的MYSQL。表引擎的不一样,其数据库的特性区别也很大。对于列式原创 2021-08-26 00:40:04 · 545 阅读 · 0 评论 -
细品事务机制(一)
细品事务机制(一)什么是事务?事务在每个系统中都会涉及,它存在的意义就时符合预期的期望。且相互关联的数据之间不会产生矛盾,也就是数据状态的一致性。数据库的经典理论需要达成一致性这个目标,需要三方面共同来努力保证:原子性:在同一项业务处理过程中事务保证了各业务正在读,写的数据同时成功,要么同时被撤销。通俗就时 要么完全完成某一件事,要么就要回到这件事情最初状态,就算你做了一般你也要进行“回滚”到最初的状态隔离性:在不同的业务中,事务保证了各业务正在读,写的数据相互独立,不被彼此影响。也许你在此想到了原创 2021-07-18 18:30:08 · 264 阅读 · 1 评论 -
细品mysql的事务隔离机制
细品mysql的事务隔离机制背景之前也有记录过mysql事务这块,温故而知新。既然聊的是Mysql事务的隔离机制,那在这里我们就默认mysql使用的是InnoDB引擎。事务这两个词也还算抽象,在这里我就把大家当做大黄鸭,都细细的聊一边。为什么MYSQL数据库需要事务在回答这个问题之前,先分析一下问题,数据库:也可以称为数据管理系统,存储数据的一个系统,将我们所需要的数据进行持久化存储,再着就是事务:这本就是一个抽象的概念,我在这里把他描述为一个过程,一个事件的成功,必然会经过一个过程,这个过程原创 2021-06-20 17:05:08 · 148 阅读 · 0 评论 -
数据同步神器Canel-day01
背景关于数据同步的方式有很多种,现在有一个场景需要将mysql数据库的数据主动同步到我们的工程中,并且能再mysql数据库客户端更改某一行的数据也能将数据同步到另一个数据库或者工程中,对于这种场景的使用我们应该怎么去实现呢?我们从问题点去分析,同步mysql数据库数据到工程中,这个很简单,那就是工程直接连接数据库直接读取。这不是主动是被动,这样的话那就肯定得数据库主动去触发了。那这肯定要改动mysql的底层源码,或者mysql又提供接口,既然说到了这里,想想mysql的主从同步机制呢?mas原创 2021-05-22 23:45:23 · 4331 阅读 · 3 评论 -
Redis的线程I/O模型
背景redis 是单线程的,为什么redis要采用单线程,而不采用多线程呢?redis 是基于内存进行存储数据的,所以CPU不是redis的瓶颈。我们一般为什么要使用多线程呢?并发处理,提高处理的效率。且我们的系统一般搜需要去进行IO读取存储在磁盘的数据(数据库,本地本文件等)才进行处理的,所以单线程的话极其容易阻塞,会导致服务吞吐量很低。但是redis并不会,redis是基于内存的,所有的运算都是内存级别的运算。那既然说到这里了,那这开个多线程那岂不是更快???? 多线程的存在也有他的问题,只原创 2020-09-07 21:51:33 · 211 阅读 · 0 评论 -
细品redis的Scan和Keys命令
背景我们有一个类似用户中心,其中有百万级别用户以user_id + id号为key存放在redis中。有一个需求是将user_为前缀进行匹配查询进行key的匹配,就在进行这个的操作命令的时候出现服务卡顿和redis 有部分链接超时。最后排查出来的问题所在就是keys的时候查出来的key太多导致的问题。具体原因那就从他这个命令的原理看起最后的解决方案是:使用scan命令Keys简介通过简单的正则就可以进行模糊匹配,没有分页,没有游标。就是暴力查找遍历。好处就是方便,坏处应有仅有,redis是原创 2020-09-01 22:29:27 · 4168 阅读 · 0 评论 -
一看就会的mysql索引优化(真实案例)
背景(使用的数据库:MYSQL 5.7 版本,InnoDB 引擎)自从服务加了Skywalking后,将大部分慢接口暴露出来。于是就有了这次慢接口的优化。大概的优化过程,没有详细的具体过程优化前:优化后:优化步骤1. 排查通过skywalking可以清楚的看到慢接口是在哪一步比较慢。通过调用情况可以清楚的看到其链路调用情况如下图:如果说你的服务没有接如这种情况监控服务,那我们可以使用阿里巴巴开源的Arthas来进行链路追踪(使用trace进行查看每一步方法的调用耗时)a原创 2020-08-25 22:46:12 · 1528 阅读 · 0 评论 -
redis的持久化存储AOF的原理
背景上篇文章我们将了RDB的原理,这节来看看AOF。AOF字面的意思是,append only file仅追加文件。AOF 是以协议文本的方式,将所有对数据库进行过写入的命令(及其参数)记录到 AOF 文件,以此达到记录数据库状态的目的。是不是和mysql的binlog日志模式还是有点类似mysql的binlog是记录所有数据库表结构变更(例如CREATE、ALTER TABLE…)以及表数据修改(INSERT、UPDATE、DELETE…)的二进制日志。AOFAOF是通过记录写入的命令来同步和原创 2020-06-07 16:50:44 · 674 阅读 · 0 评论 -
redis的持久化存储RDB的原理分析
背景想到redis,你的第一反应是什么呢?redis很快,我们一般一用它做缓存,再想想他为什么快呢?也许你的第一反应和我的第一反应是一样的,因为他是基于内存存储的,IO多路复用等。那么既然是基于内存存储的,那要是redis当宕机了那岂不是内存的数据都无法恢复了(在一些特殊情况下数据比较重要的情况)。那redis是如何解决这一问题?那就是redis的持久化机制。redis持久化机制redis 有两种持久化方式,RDB和AOF,今天我们主要先聊聊RDB持久化数据1. RDB权威指南(redis官方原创 2020-06-07 00:35:23 · 1939 阅读 · 0 评论 -
520初识MongoDB
背景由于我们在开发的过程中难免会遇到数据库选型的问题,那么数据库的选型那我们必须通过结合我们的业务场景还有他们的设计初衷,及各自在各个方面的优势。现在我们就在业务开发中遇到了选择 mongoDB还时MYsql。之前没有怎么了解过mongoDB,那今天就开始我的mongoDB第一步。设计的初衷建立一种灵活,高效,易于扩展,功能完备的数据库。1. 丰富的数据模型mongo是面向文档的数据库,为了获得更好的扩展性采用的不是关系型数据库,使用一条记录就可以表示非常复杂的层次关系没有固定的模式,文档的键原创 2020-05-21 02:12:51 · 197 阅读 · 0 评论