- 博客(33)
- 收藏
- 关注
RSS订阅原创 Redis客户端选型之Jedis vs Redisson
本文的主要内容为对比Redis的两个框架：Jedis与Redisson，分析各自的优势与缺点，为项目中Java缓存方案中的Redis编程模型的选择提供参考。
2024-07-01 09:24:05
331
原创 工作流引擎技术选型之Activiti vs Camunda vs Flowable
先看一下维基百科对于工作流的定义：工作流（Workflow），是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。工作流建模，即将工作流程中的工作如何前后组织在一起的逻辑和规则，在计算机中以恰当的模型表达并对其实施计算。工作流要解决的主要问题是：为实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。简单来说，工作流就是对业务的流程化抽象。WFMC（工作流程管理联盟） 给出了工作流参考模型如下：举一个例子，比如公司办公的 OA 系统，就存在大量的申请审批流程。
2024-06-28 09:34:52
940
原创 分布式系统选型之Kubernetes (K8s) vs Spring Cloud
Kubernetes 是由 Google 开发并捐赠给 Cloud Native Computing Foundation (CNCF) 的开源容器编排平台。Kubernetes 的主要目的是自动化应用程序的部署、扩展和管理。它允许开发者和运维人员高效地管理成千上万的容器化应用，并确保这些应用能够高可用、可扩展和易于维护。Kubernetes是一个容器编排平台，属于基础设施层，主要关注容器的部署、管理和扩展。它有一个丰富的生态系统，包括 Helm、Istio、Prometheus 等工具。
2024-06-27 16:04:30
946
原创 微服务配置中心选型之Config vs Apollo vs Nacos
配置是独立于程序的只读变量配置首先是独立于程序的，同一份程序在不同的配置下会有不同的行为。其次，配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置。常见的配置有：DB Connection Str、Thread Pool Size、Buffer Size、Request Timeout、Feature Switch、Server Urls等。配置伴随应用的整个生命周期配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。
2024-06-27 15:39:42
749
原创 大数据处理引擎选型之 Hadoop vs Spark vs Flink
随着大数据时代的到来，处理海量数据成为了各个领域的关键挑战之一。为了应对这一挑战，多个大数据处理框架被开发出来，其中最知名的包括Hadoop、Spark和Flink。本文将对这三个大数据处理框架进行比较，以及在不同场景下的选择考虑。Hadoop是大数据处理领域的先驱，其核心组件包括Hadoop Distributed File System（HDFS）和MapReduce。HDFS负责将大数据分布式存储在多台服务器上，而MapReduce则负责将数据分成小块进行并行处理。
2024-06-27 11:42:05
605
原创 数据存储选型之 Elasticsearch vs Clickhouse
Clickhouse与Elasticsearch对比Clickhouse的优缺点。硬件资源成本更低，同等场景下，Clickhouse占用的资源更小。人力成本更低，新人学习、开发单测以及测试方面都更加友好，更容易介入。OLAP场景下Clickhouse比Elasticsearch更适合，聚合计算比Elasticsearch更精缺、更快，更节省服务器计算资源。写入性能更高，同等情况下是Elasticsearch的5倍，写入时消耗的服务器资源更小。
2024-06-27 11:13:41
1080
原创 流量控制组件选型之 Sentinel vs Hystrix
SentinelHystrix隔离策略信号量隔离线程池隔离/信号量隔离熔断降级策略基于响应时间或失败比率基于失败比率实时指标实现滑动窗口滑动窗口（基于 RxJava）规则配置支持多种数据源支持多种数据源扩展性多个扩展点插件的形式基于注解的支持支持支持限流基于 QPS，支持基于调用关系的限流不支持流量整形支持慢启动、匀速器模式不支持系统负载保护支持不支持控制台开箱即用，可配置规则、查看秒级监控、机器发现等不完善常见框架的适配。
2024-06-27 10:56:30
931
2
原创 消息队列选型之 Kafka vs RabbitMQ
消息队列即 Message+Queue，消息可以说是一个数据传输单位，它包含了创建时间、通道/主题信息、输入参数等全部数据；队列（Queue）是一种 FIFO（先进先出）的数据结构，编程语言一般都内置(内存中的)队列实现，可以作为进程间通讯（IPC）的方法。使用队列最常见的场景就是生产者/消费者模式：生产者生产消息放到队列中，消费者从队列里面获取消息消费。
2024-06-27 10:11:17
1407
原创 Java后端开发技术选型
本文介绍Java后端开发的技术选型。持续更新。本文中的每一项都按照从上到下为从好到差的顺序排列技术栈，并给它们打分（满分100分）。我推荐使用最高分的那个，也就是第一个。
2024-06-27 09:44:02
872
原创 MySQL集群高可用架构之MySQL InnoDB Cluste
MySQL的高可用架构无论是社区还是官方，一直在技术上进行探索，这么多年提出了多种解决方案，比如 MMM, MHA, NDB Cluster, Galera Cluster, InnoDB Cluster, 腾讯的PhxSQL, MySQL Fabric., aliSQL。MySQL官方在2017年4月推出了一套完整的、高可用的Mysql解决方案 - MySQL InnoDB Cluster, 即一组MySQL服务器可以配置为一个MySQL集群。
2024-06-24 15:03:44
672
原创 MySQL集群高可用架构之双主双活+keepalived
MySQL双主双活是指两台mysql服务器mysql-1、mysql-2都为master主节点服务器，同时又是对方的slave从节点，每个数据库都可作为主数据库使用，并将对数据库操作的数据同步至另外一台mysql服务中。
2024-06-24 14:28:01
1152
原创 MySQL集群高可用架构之MHA
一、MHA概述通过"三W一H"来介绍MHA。1.1 为什么要用MHA？Master的单点故障问题1.2 什么是 MHA？MHA（Master High Availability）是一套优秀的MySQL高可用环境下故障切换和主从复制的软件。MHA 的出现就是解决MySQL 单点的问题。MySQL故障切换过程中，MHA能做到0-30秒内自动完成故障切换操作。MHA能在故障切换的过程中最大程度上保证数据的一致性，以达到真正意义上的高可用。1.3 MHA 的组成。
2024-06-24 14:14:23
757
原创 MySQL 高可用方案选型解析
高可用是数据库永恒的话题，高可用方案也是受数据库爱好者关注的重点技术之一。在MySQL二十多年的发展历程中，针对百花齐放，各具特色，这也是这款开源数据库能让人着迷的地方。例如，早些年的MMM、MHA等等。随着MySQL官方的不断发力，在基于MySQL复制的基础上，推出了一系列的高可用方案，例如，主从半同步复制、InnoDB ReplicaSet、组复制（MGR）、InnoDB Cluster，及目前新的InnoDB ClusterSet。
2024-06-13 17:39:56
1022
原创 分布式事务解决方案
分 布 式 服 务 购 物 逻 辑 伪 代 码 实 现我们以快捷支付的方式在商城购买商品为例（即：下完订单自动支付），看一下分布式事务在实现上与非分布式的区别。前提是我们针对订单服务库存服务和支付服务这3个服务都有对应的3个数据库，分别是订单库库存库和支付库。
2024-06-12 08:58:35
935
原创 MySQL索引详解
B树中每个节点中包含key值以及data值，而每一个节点的存储空间是有限的(MySQL默认16K)，如果data中存放的数据较大时，将会导致每个节点能存储的key的数量很小，所以当数据量很多，且每行数据量很大的时候，同样会导致树的高度变得很高，增大查询时的磁盘IO次数，进而影响查询效率。不支持范围查询的快速查找，而在实际的应用中，数据库范围查询的频率非常高，以下的一种情况是我查找10和35之间的数据，查找到15之后，需要回到根节点重新遍历查找，需要从根节点进行多次遍历，查询效率有待提高。
2024-06-05 14:41:02
967
原创 MYSQL 常用监控命令
任何东西不应过重关注其外表，要注重内在的东西，往往绚丽的外表下会有对应的负担和损耗。mysql数据库的监控支持通过SQL方式从performance_schema库中访问对应的表数据，前提是初始化此库并开启监控数据写入。对于监控而言，不在于手段的多样性，而需要明白监控的本质，以及需要的监控项内容，找到符合自身项目特色的监控方式。在选择监控工具对mysql监控时，需要关注监控工具本身对于数据库服务器的消耗，不要影响到其自身的使用。
2024-06-05 09:47:30
865
原创 分库分表后怎么分页查询
全局查询法：这种方案最简单，但是随着页码的增加，性能越来越低禁止跳页查询法：这种方案是在业务上更改，不能跳页查询，由于只返回一页数据，性能较高二次查询法：数据精确，在数据分布均衡的情况下适用，查询的数据较少，不会随着翻页增加数据的返回量，性能较高。
2024-06-04 10:10:01
1280
1
原创 MySQL命令大全
MySQL的基本操作可以包括两个方面：MySQL常用语句如高频率使用的增删改查（CRUD）语句和MySQL高级功能，如存储过程，触发器，事务处理等。而这两个方面又可以细分如下：MySQL常用语句MySQL的高级功能。
2024-06-03 17:45:54
743
原创 MySQL主从同步延迟的原因、排查和解决方案
master端修改linux、Unix文件系统中文件的etime属性， 由于每当读文件时OS都会将读取操作发生的时间回写到磁盘上，对于读操作频繁的数据库文件来说这是没必要的，只会增加磁盘系统的负担影响I/O性能。根本原因：从库relay log日志执行replay重放延迟，当主库的 TPS 并发较高，产生的 DDL 数量超过从库一个 SQL 线程所能承受的范围，那么延时就产生了，当然还有就是可能与从库的大型 query 语句产生了锁等待。采用好服务器，比如4u比2u性能明显好，2u比1u性能明显好。
2024-06-03 16:14:51
1002
原创 分布式 ID 详解
日常开发中，我们需要对系统中的各种数据使用 ID 唯一表示，比如用户 ID 对应且仅对应一个人，商品 ID 对应且仅对应一件商品，订单 ID 对应且仅对应一个订单。我们现实生活中也有各种 ID，比如身份证 ID 对应且仅对应一个人、地址 ID 对应且仅对。应简单来说，ID 就是数据的唯一标识。分布式 ID 是分布式系统下的 ID。分布式 ID 不存在与现实生活中，属于计算机系统中的一个概念。我简单举一个分库分表的例子。我司的一个项目，使用的是单机 MySQL。
2024-05-31 10:03:12
944
原创 MySQL千万数据下如何优化limit
如果主键id有序，可以用子查询优化如果主键id是无序的，可以用inner join来优化子查询或者内连接中涉及的字段都要创建为联合索引使用索引覆盖减少回表。
2024-05-30 15:14:21
923
原创 解决Redis和MySQL结果不一致的问题
首先，请求 A 进行写操作，删除缓存；在这个过程中，我们首先删除了缓存中的数据，保证了缓存和数据库中的数据一致性，然后再将最新的数据写入缓存，保证了读取数据的效率。相信很多同学都遇到过这种情况：在一个数据库读写分离架构中，一个请求进行更新操作，另一个请求进行查询操作，结果查询出来的数据却不是最新的，这就是因为数据还没来得及同步到从库，而查询请求却已经到达了从库，所以查询到的是旧值。但是，这种方案会带来一个问题：当数据库中的数据发生变化时，缓存中的数据却没有及时更新，导致缓存中的数据和数据库中的数据不一致。
2024-05-30 14:53:56
600
原创 MySQL性能优化十个实用技巧
慢查询是指在执行时，需要的时间超过了特定阈值的SQL查询。这个时间阈值通常是根据你的应用程序性能要求和硬件规格来决定的。对于一个小型应用而言，慢查询可能是需要1秒完成的查询，而对于大型应用来说，慢查询的阈值可能会更高。慢查询通常是由于查询语句的执行计划不佳或表中的数据量过大而引起的。当慢查询发生时，需要尽快发现问题并解决它，以避免对应用程序的性能产生不利影响。慢查询可能会对应用程序、数据库和用户造成负面影响。因此，我们需要及时发现和解决慢查询问题，以保持应用程序的性能。
2024-05-30 14:37:38
824
原创 MySQL缓冲池（buffer pool）
如果在业务中没有做大量的全表扫描，则可以将innodb_old_blocks_pct增大，减小变量innodb_old_blocks_time的时长，让有用的查询缓存数据尽量缓存在innodb_buffer_pool_size中，减小磁盘IO，提高性能。如果在业务中做了大量的全表扫描，则可以将变量innodb_old_blocks_pct的设置减小，增大变量innodb_old_blocks_time的时长，不让这些无用的查询数据进入old区域，尽量不让缓存在young区域的有用的数据被立即刷掉。
2024-05-30 11:12:31
553
原创 为什么MySQL默认的隔离级别是RR而大厂使用的是RC?
但也会有个问题， 假设主库在存储引擎提交之前挂了，那么很明显这个事务是不成功的，但由于对应的Binlog已经做了Sync操作， 从库已经收到了这些Binlog，并且执行成功，相当于在从库上多了数据，也算是有问题的，但多了数据，问题一般不算严重。Master 接收到来自 Slave 的 IO 进程的请求后，负责复制的 IO 进程根据 Slave 的请求信息，读取相应日志内容，返回给Slave 的IO进程，并将本次请求读取的 bin-log 文件名及位置一起返回给 Slave 端 Slave 端的 IO。
2024-05-30 11:11:40
679
原创 MySQL锁
在 MySQL 中，当发生死锁时，MySQL 使用一种叫做"最小成本回滚"（InnoDB 中称为"最小编号事务回滚"）的策略来选择一个事务作为牺牲者并进行回滚，最小成本回滚策略是 MySQL 的默认行为，它会自动选择牺牲者并回滚事务。最小成本回滚策略的原理是选择最小成本的事务作为牺牲者。
2024-05-30 10:59:04
879
原创 MySQL事务---MVCC详解
Read View遵循的可见性算法主要是将要被修改的数据的最新记录中的DB_TRX_ID（当前事务id）取出来，与系统当前其他活跃事务的id去对比，如果DB_TRX_ID跟Read View的属性做了比较，不符合可见性，那么就通过DB_ROLL_PTR回滚指针去取出undolog中的DB_TRX_ID做比较，即遍历链表中的DB_TRX_ID，直到找到满足条件的DB_TRX_ID,这个DB_TRX_ID所在的旧记录就是当前事务能看到的最新老版本数据。不加锁的select操作就是快照读，即不加锁的非阻塞读；
2024-05-30 10:31:19
862
原创 MySQL开发规范和基础
俗话说，无规矩不成方圆。而规范的本质不是解决问题，而是有效杜绝一些潜在问题，所以规范的意义很明确，能够让彼此的工作都可以互利互惠。但是从工作实践来说，大家对于数据库开发规范还是存在一些误解，主要表现在以下三个方面:(1)有了开发规范，但是规范粒度太粗，规范落实没有参考。(2)制定了太过细致的开发规范，导致在工作落实中难以适应业务场景。(3)有了开发规范，束之高阁了，没有一个持续的改进过程。
2024-05-30 10:03:19
627
原创 什么是死锁？如何在MySQL中避免死锁？
因此，理解事务的执行顺序、锁定的资源以及适当的隔离级别，以及使用合适的死锁监控和处理策略，都是避免和处理死锁的关键。如果事务A需要同时锁定资源X和Y，而事务B需要同时锁定资源Y和X，可以通过按照相同的顺序来获取锁，以避免死锁。死锁是指在多个事务并发执行时，每个事务都在等待其他事务释放资源，从而导致所有事务都无法继续执行的一种情况。3、使用事务超时：在事务中设置适当的超时时间，如果事务在指定的时间内无法获取所需的锁定资源，可以自动回滚事务，避免长时间的等待。表、行、页等）的情况下。
2024-05-29 17:25:25
275
1
原创 MySQL日志文件：redo log、undo log和binlog详解
MySQL 日志 主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。其中，比较重要的还要属二进制日志 binlog（归档日志）和事务日志 redo log（重做日志）和 undo log（回滚日志）。1、重做日志（redo log）2、回滚日志（undo log）3、归档日志（binlog）4、错误日志（errorlog）5、慢查询日志（slow query log）6、一般查询日志（general log）7、中继日志（relay log）
2024-05-29 17:07:22
1181
2
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人