m0_61802230的博客

大表优化

redis vm 机制

导读想象一下遇到下面的场景你会如何处理：手机号是否重复注册用户是否参与过某秒杀活动伪造请求大量 id 查询不存在的记录，此时缓存未命中,如何避免缓存穿透针对以上问题常规做法是：查询数据库，数据库硬扛，如果压力并不大可以使用此方法，保持简单即可。改进做法：用 list/set/tree 维护一个元素集合，判断元素是否在集合内，时间复杂度或空间复杂度会比较高。如果是微服务的话可以用 redis 中的 list/set 数据结构, 数据规模非常大此方案的内存容量要求可能会非常高。这些场景有个共同

哨兵的作用哨兵是redis集群架构中非常重要的一个组件，主要功能如下：集群监控：负责监控redis master和slave进程是否正常工作消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员故障转移：如果master node挂掉了，会自动转移到slave node上配置中心：如果故障转移发生了，通知client客户端新的master地址哨兵的核心知识故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式

导读RDB 和 AOF 对比：持久化方式选择如果对数据安全性要求极高，应该同时使用两种持久化方式。如果可以承受若干时间内的数据丢失，可以只使用 RDB 持久化。不建议只使用 AOF 持久化，因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度要比 AOF 恢复的速度要快。RDB 和 AOF 的恢复优先级如果 Redis 同时使用 RDB 和 AOF 持久化，Redis 会优先使用 AOF 进行恢复数据。在启动 Redis 时，如果已经存在了

RDB持久化触发机制手动触发手动触发分别对应save和bgsave命令：save命令：同步，在主线程中保存快照；阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用；bgsave命令：异步，Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。堵塞只发生在fork阶段，一般时间很短；BGSAVE命令是针对SAVE堵塞问题做的优化。因此Redis内部所有的设计RDB的操作都采用BGSAVE的方式，而sav

sql注入发生的时间，sql注入发生的阶段在sql预编译阶段，当编译完成的sql不会产生sql注入一、采用jdbc操作数据时候String sql = "update ft_proposal set id = "+id;PreparedStatement prepareStatement = conn.prepareStatement(sql);prepareStatement.executeUpdate();preparedStatement 预编译对象会对传入sql进行预编译，那么当传入.

导读最近在学习Redis，那么首先需要了解的就是Redis的配置文件，弄懂其配置也是接下来学习Redis的基础。配置文件解析################################## INCLUDES(导入) ################################### # 引入其他配置文件include /path/to/local.conf ################################## MODULES(模块) ###############

导读乐观锁介绍：watch指令在redis事物中提供了CAS的行为。为了检测被watch的keys在是否有多个clients同时改变引起冲突，这些keys将会被监控。如果至少有一个被监控的key在执行exec命令前被修改，整个事物将会回滚，不执行任何动作，从而保证原子性操作，并且执行exec会得到null的回复。乐观锁工作机制：watch 命令会监视给定的每一个key，当exec时如果监视的任一个key自从调用watch后发生过变化，则整个事务会回滚，不执行任何动作。注意watch的key是对整个连

导读大家都知道 Redis 中的键会设置过期时间，当到达过期时间时会通过一定策略清除对应 key，但是 redis 内存是由上限的，当达到内存上限时，就要通过一定策略淘汰掉相应 kv 键值对。Redis 内存上限maxmemory 配置选项使用来配置 Redis 的存储数据所能使用的最大内存限制。可以通过在内置文件redis.conf中配置，也可在Redis运行时通过命令CONFIG SET来配置。例如，我们要配置内存上限是100M的Redis缓存，那么我们可以在 redis.conf 配置如下：m

导读提起缓存，大家应该都不陌生，开始时，如果你的业务处于起步阶段，流量非常小，那无论是读请求还是写请求，直接操作数据库即可，这时你的架构模型是这样的：但随着业务量的增长，你的项目请求量越来越大，这时如果每次都从数据库中读数据，那肯定会有性能问题。这个阶段通常的做法是，引入「缓存」来提高读性能，架构模型就变成了这样：这时候就会处出现一个问题：缓存读写策略，即缓存的读写问题，之前只需要读写数据库即可，现在多了缓存，又该如何读写呢，怎么保证缓存一致性呢？下面主要讲解Redis常用的三种缓存策略。Ca

导语大家知道binlog可以用来归档，也可以用来做主备同步，但它的内容是什么样的呢？为什么备库执行了binlog就可以跟主库保持一致了呢？我下面的内容就是针对这个问题。MySQL主备的基本原理在状态1中，客户端的读写都直接访问节点A，而节点B是A的备库，只是将A的更新都同步过来，到本地执行。这样可以保持节点B和A的数据是相同的。当需要切换的时候，就切成状态2。这时候客户端读写访问的都是节点B，而节点A是B的备库。**注意：节点B（也就是备库）设置成只读（readonly）模式。**主要有以下几个原

问题我们知道，只要redo log和bin log保证持久化到磁盘，就能确保MySQL异常重启后，数据可以恢复。那他们是如何持久化到磁盘的呢？今天就探讨这个问题？binlog的写入机制事务执行过程中，先把日志写到binlog cache，事务提交的时候，再把binlog cache写到binlog文件中。但是我们要明确，一个事务的binlog是不能被拆开的，因此不论这个事务多大，也要确保一次性写入。这就涉及到了binlog cache的保存问题。系统给binlog cache分配了一片内存，每个

问题首先要明确你的数据库突然压力变大是因为什么，之后才能采取出相应的措施来解决。短连接过多那什么是短连接呢？正常的短连接模式就是连接到数据库后，执行很少的SQL语句就断开，下次需要的时候再重连。如果使用的是短连接，在业务高峰期的时候，就可能出现连接数突然暴涨的情况。我们知道在MySQL建立连接的过程，成本是很高的。除了正常的网络连接三次握手外，还需要做登录权限判断和获得这个连接的数据读写权限。在数据库压力比较小的时候，这些额外的成本并不明显。短连接模型存在一个风险，就是一旦数据库处理得慢一

先说明：Mysql 在Repeatable Read底下不会发生幻读的情况，因为Mysql有间隙锁的可以防止幻读。那什么是间隙锁？间隙锁跟MVCC一起工作。实现事务处理：Repeatable Read隔离级别： 采用Next-key Lock 来解决幻读问题.因此 Mysql 在Repeatable下面 幻读，可重复读，脏读 三者都不会发生read committed隔离级别：采用Record锁,不会出现脏读，但是会产生"幻读"问题. 也会出现可重复读。什么是MVCC 呢？MVCC只是工

问题描述在MySQL中，有很多看上去逻辑相同，但性能却差异巨大的SQL语句。对这些语句使用不当的话，就会不经意间导致整个数据库的压力变大。案例分析条件字段函数操作对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。不过优化器在个问题上确实有“偷懒”行为，即使是对于不改变有序性的函数，也不会考虑使用索引。比如，对于select * from tradelog where id + 1 = 10000这个SQL语句，这个加1操作并不会改变有序性，但是MySQL优化器还是不

count()的语义count()是一个聚合函数，对于返回的结果集，一行行地判断，如果count函数的参数不是NULL，累计值就加1，否则不加。最后返回累计值。需要注意的是，下面的讨论是基于InnoDB引擎的。count(*)、count(主键id)和count(1)首先说明一点，count(*)、count(主键id)和count(1) 都表示返回满足条件的结果集的总行数；而count(字段），则表示返回满足条件的数据行里面，参数“字段”不为NULL的总个数。至于分析他们之间性能差别的时候，可以

基础架构MySQL的基本架构示意图大体来说，MySQL可以分为Server层和存储引擎层两部分。Server层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖MySQL的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。而存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是InnoDB，它从MySQL 5.5.5版本开