beikekaka的博客

​​​​​​并发插入引发的死锁问题排查_zxcodestudy的博客-CSDN博客_并发insert死锁讲讲insert on duplicate key update 的死锁坑_li563868273的博客-CSDN博客MySQL常见的七种锁详细介绍_Saintyyu的博客-CSDN博客_mysql锁...

hashMap术语介绍：桶： 就是hashmap的table数组bin: 就是挂在数组上的链表TreeNode: 红黑树capacity： table总容量MIN_TREEIFY_CAPACITY ：64转化为红黑树table最小大小TREEIFY_THRESHOLD ：8转化为红黑树的阈值loadFactor:0.75table扩容因子，当实际length大于等于capacity*loadFactor时...

脏读，脏数据是指未提交的数据。如果读到了脏数据，即一个事务可以读到另外一个事务中未提交的数据 不可重复读是指在一个事务内多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务的两次读数据之间，由于第二个事务的修改，第一个事务两次读到的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为不可重复读。InnoDB存储引擎中，通过使用Next-Key Lock算法来避免不可重复读的问题。 InnoDB存储引擎在REPEATABLE READ事务隔离级

MySQL在 5.0版本中引入新特性：索引合并优化(Index merge optimization)，当查询中单张表可以使用多个索引时，同时扫描多个索引并将扫描结果进行合并。该特新主要应用于以下三种场景：1、 对OR语句求并集，如查询SELECT * FROM TB1 WHERE c1="xxx" OR c2=""xxx"时，如果c1和c2列上分别有索引，可以按照c1和c2条件进行查询，再将查询结果合并（union）操作，得到最终结果2、 对AND语句求交集，如查询SELECT * FROM TB

目前，Mysql作为常用的数据库，在各类业务中被广泛运用。但是其设计并非是十全十美，一些我们认为“高效“的语句，在执行时会花费大量的时间，导致页面出现超时错误。这里举一些简单的bad case，希望大家以后处理慢sql时能有所参考。（不想研究分析过程的，请移步总结）子查询是一个坑业务中，我们定义了两张表：用户参加项目表（user_project）和用户公会情况表（union_user）。user_project表中有user_id和project_id字段来标记用户参与项目的对应关系，同时这两个

union 和 union all 会走索引，同一个表的不同索引或者不同表的索引都可以走到 简单的in能够命中索引， in （1，2） 可以走到索引，in 子查询 走不到索引 对于or，新版的MySQL能够命中索引 对于!=，负向查询肯定不能命中索引 like查询是以%开头不能命中索引 多列索引不查询前一部分不能命中索引 查询字符型不用引号不能命中索引（字符型最好用前缀索引） ...

integer i=127;integer j =127;system.out.println(i==j);i=128;j=128;system.out.println(i==j);i=new integer(127);j=new integer(127);system.out.println(i==j);输出结果为 true、false、false。这是因为jvm的缓存机制导致的。jvm在运行时创建了一个缓存区域，并创建了一个integer的数组。这个数组存储了-128至127的值

假设一个接口里面有两个方法：package demo.long;public interface CustomerService { public void doSomething1(); public void doSomething2(); } 接口实现类如下：package demo.long.impl;import demo.long.CustomerService; public class CustomerServiceIm..

本文目录一 前言 二 一致性方案 三 先更新数据库，再更新缓存 四 先删缓存，再更新数据库 五 先更新数据库，再删缓存回到目录一 前言首先，缓存由于其高并发和高性能的特性，已经在项目中被广泛使用。在读取缓存方面，大家没啥疑问，都是按照下图的流程来进行业务操作但是在更新缓存方面，对于更新完数据库，是更新缓存呢，还是删除缓存。又或者是先删除缓存，再更新数据库，其实大家存在很大的争议本文由以下三个部分组成 1、讲解缓存更新策略 2、对每种策略进行缺点分析 3、针对缺点给出改进方案

2018年，Apache Kafka以一种特殊的设计和方法实现了强语义的exactly-once和事务性。热泪盈眶啊！这篇文章将讲解kafka中exactly-once和事务操作的原理，具体为（1）exactly-once在kafka中的定义。（2）数据生产者“幂等操作”，kafka的事务性以及exactly-once实现原理。（3）exactly-once的流处理。1. 什么是恰好...

原文地址：https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/笔者做了翻译和整理，有误之处请指正。很高兴地告诉大家，具备新的里程碑意义的功能的Kafka 0.11.x版本（对应 Confluent Platform 3.3）已经release，该版...