程序源日志的博客

逻辑删除需要在表中额外增加一个删除状态字段，用于记录数据是否被删除。在所有的业务查询的地方，都需要过滤掉已经删除的数据。通过这种方式删除数据之后，数据任然还在表中，只是从逻辑上过滤了删除状态的数据而已。其实对于这种逻辑删除的表，是没法加唯一索引的。为什么呢？假设之前给商品表中的`name`和`model`加了唯一索引，如果用户把某条记录删除了，delete_status设置成1了。后来，该用户发现不对，又重新添加了一模一样的商品。由于唯一索引的存在，该用户第二次添加商品会失败，即使该商品

客户端分片是把分片的逻辑放在Redis客户端实现，（比如：jedis已支持Redis Sharding功能，即ShardedJedis），通过Redis客户端预先定义好的路由规则(使用一致性哈希)，把对Key的访问转发到不同的Redis实例中，查询数据时把返回结果汇集。比如，一个分布式的存储系统，要将数据存储到具体的节点上，如果采用普通的hash方法，将数据映射到具体的节点上，如mod(key,d)，key是数据的key，d是机器节点数，如果有一个机器加入或退出这个集群，则所有的数据映射都无效了。

1. Redis 主从面试官经常会问到Redis的高可用。Redis高可用回答包括两个层面，一个就是;另外一个就是保证。1.1 Redsi主从概念1.2 Redis 主从同步过程Redis主从同步包括三个阶段。第一阶段：主从库间建立连接、协商同步。psyncpsyncFULLRESYNCrunIDoffsetbgsaveRDBRDBhgetall如何解决主从数据不一致问题呢？1.3.2 读取过期数据如果使用Redis版本低于3.2，读从库时，并不会判断数据是否过期，而是会。

是一种"事务性"的保障，它的目的是保证程序在异常的情况下运行完毕，同时它还会告知程序员程序中出错的详细信息（这种详细信息有时要依赖于程序员设计）。看一下这个类中关于除运算的方法，如果你是新手你可能会直接返回计算结果，根本不去考虑什么参数是否正确，是否合法（当然可以原谅，谁都是这样过来的）。异常是程序处理意外情况的机制，当程序发生意外时，我们需要尽可能多的得到意外的信息，包括发生的位置，描述，原因等等。异常的本意是好的，让我们试图修复程序，但是现实中我们修复的几率很小，我们很多时候就是用它来记录出错的信息。

在框架集成中，细心的读者会发现，还有很多功能是可以扩展的，感兴趣的读者可以参照本书作者在SSI的基础上开发的“颐凡Java应用开发平台”。另外，一个庞大的综合Java EE系统，还包括相关批处理程序，因此本章也介绍了常用的SpringBatch技术，读者朋友可以根据实际项目的需求来灵活运用。第14章，开源框架，本章介绍了开源框架的选择、使用、开发以及发布中的必备技术。希望大家学习完本文之后，能够建立起自己的java架构技能体系，并且能够灵活运用到自己的工作之中，助自己更好的成长，成为优秀的。

这时如果要恢复服务的话，需要人工介入，选择一个「从节点」切换为「主节点」，然后让其他从节点指向新的主节点，同时还需要通知上游那些连接 Redis 主节点的客户端，将其配置中的主节点 IP 地址更新为「新主节点」的 IP 地址。这样也不太“智能”了，要是有一个节点能监控「主节点」的状态，当发现主节点挂了 ，它自动将一个「从节点」切换为「主节点」的话，那么可以节省我们很多事情啊！Redis 在 2.8 版本以后提供的**哨兵（\*Sentinel\*）机制**，它的作用是实现**主从节点故障转移**。它

Apache [Pulsar](https://so.csdn.net/so/search?q=Pulsar&spm=1001.2101.3001.7020)是Apache软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性，被看作是云原生时代实时消息流传输、存储和计算最佳解决方案。

Memcached 利用 slab allocation 机制来分配和管理内存，它按照预先规定的大小，将分配的内存分割成特定长度的内存块，再把尺寸相同的内存块分成组，数据在存放时，根据键值 大小去匹配 slab 大小，找就近的 slab 存放，所以存在空间浪费现象。缓存是用于存储数据的硬件或软件的组成部分，以使得后续更快访问相应的数据。这个操作有一个比较大的问题，在对缓存删除完之后，有一个读请求，这个时候由于缓存被删除所以直接会读库，读操作的数据是老的并且会被加载进入缓存当中，后续读请求全部访问的老数据。

以上三种严格地说还算不上jvm的调优，只是用了jvm工具把代码中存在的问题找了出来。我们进行jvm的主要目的是尽量减少停顿时间，提高系统的吞吐量。但是如果我们没有对系统进行分析就盲目去设置其中的参数，可能会得到更坏的结果，jvm发展到今天，各种默认的参数可能是实验室的人经过多次的测试来做平衡的，适用大多数的应用场景。如果你认为你的jvm确实有调优的必要，也务必要取样分析，最后还得慢慢多次调节，才有可能得到更优的效果。

大家好，今天跟大家聊聊分库分表。什么是分库分表为什么需要分库分表如何分库分表什么时候开始考虑分库分表分库分表会导致哪些问题分库分表中间件简介分库：就是一个数据库分成多个数据库，部署到不同机器。分表：就是一个数据库表分成多个表。

在正常情况下，客户端的异步调用可以通过callback来处理消息发送失败或者超时的情况，但是，一旦producer被非法的停止了，那么buffer中的数据将丢失，broker将无法收到该部分数据。Broker丢失消息是由于Kafka本身的原因造成的，kafka为了得到更高的性能和吞吐量，将数据异步批量的存储在磁盘中。消息的刷盘过程，为了提高性能，减少刷盘次数，kafka采用了批量刷盘的做法。中有实现，实现原理是将异步刷盘的流程进行阻塞，等待响应，类似ajax的callback或者是java的future。

遇到这种问题，我们一般也会想到是因为索引。那除开索引之外，还有哪些因素会导致数据库查询变慢呢？有哪些操作，可以提升mysql的查询能力呢？今天这篇文章，我们就来聊聊会导致数据库查询变慢的场景有哪些，并给出原因和解决方案。我们先来看下，一条查询语句下来，会经历哪些流程。比如我们有一张数据库表我们平常写的应用代码（go或C++之类的），这时候就叫客户端了。客户端底层会带着账号密码，尝试向mysql建立一条TCP长链接。mysql的连接管理模块会对这条连接进行管理。建立连接后，客户端执行一条查询sql语句。比如

很多人只知道是 K/V NoSQl 内存数据库，单线程……这都是没有全面理解 Redis 导致无法继续深问下去。这个问题是基础摸底，我们可以从 Redis 不同数据类型底层的数据结构实现、完全基于内存、IO 多路复用网络模型、线程模型、渐进式 rehash……我们可以先说到底有多快，根据官方数据，Redis 的 QPS 可以达到约 100000（每秒请求数），有兴趣的可以参考官方的基准程序测试《How fast is Redis？》，地址：/docs/reference/optimization/bench

软件开发通常会提到一个名词 “三高”，即高并发、高性能、高可用。具体的指标定义，如：高并发方面要求QPS 大于 10万；高性能方面要求请求延迟小于 100 ms；高可用方面要高于 99.99%。高并发我们使用 QPS（Queries Per Second，每秒查询率）来衡量系统承载能力。架构策略有哪些？正所谓双拳难敌四手，高并发撑场面的首选方案就是集群化部署，一台服务器承载的QPS有限，多台服务器叠加效果就不一样了。如何将流量转发到服务器集群，这里面就要用到负载均衡，比如：LVS 和 Nginx。常用的负

自从软件开发的早期(1960年代)以来，解决大型软件系统中的复杂性一直是一项艰巨的任务。多年来，软件工程师和架构师为解决软件系统的复杂性进行了许多尝试：David Parnas的模块化和信息隐藏(1972)，Edsger W. Dijkstra的关注分离(1974)，面向服务的体系结构(1998)。他们所有人都使用了久经考验的成熟技术来解决大型系统的复杂性：分而治之。自2010年代以来，这些技术不足以解决Web规模应用程序或现代大型企业应用程序的复杂性。结果，架构师和工程师开发了一种新方法来解决现代软件系统

编程喵 实战项目里需要做一个定时发布文章的功能，一开始我想用 Spring Task，于是研究了一番，发现 Spring Task 用起来确实简单，但对于复杂业务却也无能为力。于是我就把注意力放到了 Quartz 上面，这是一款老而弥坚的开源任务调度框架。记得我在 14 年开发大宗期货交易平台的时候就用到了它，每天凌晨定时需要统计一波交易数据，生成日报报表，当时配合 Cron 表达式用的。可惜后来平台稳定了，新的政策出来了，直接把大宗期货交易灭了。于是我发财的机会也随着破灭了。想想都觉得可惜，哈哈哈。时光荏

本文将会对 Kafka 消费者拉取消息流程进行深度分析之后，对 Kafka 消费者顺序消费线程模型进行一次实践与优化。在讲实现 Kafka 顺序消费线程模型之前，我们需要先深入分析 Kafka 消费者的消息拉取机制，只有当你对 Kafka 消费者拉取消息的整个流程有深入的了解之后，你才能够很好地理解本次线程模型改造的方案。我先给大家模拟一下消息拉取的实际现象，这里 max.poll.records = 500。可以发现，在消息没有堆积时，消费者拉取时，如果某个分区没有的消息不足 500 条，会从其他分区凑够

在分布式系统中，由于redis分布式锁相对于更简单和高效，成为了分布式锁的首先，被用到了很多业务场景当中。apollo、nocos等的出现，让zookeeper的地位越来越低了。zookeeper分布式锁复杂度更高，想把它使用好并不容易。所以我们还是好好使用redis分布式锁吧。不是说用了redis分布式锁，就可以高枕无忧了，如果没有用好，也会引来一些意想不到的麻烦。今天我们重点聊聊redis分布式锁的一些坑，给有需要的朋友一个参考。

分布式分布式事务本身就是一个技术难题，业务中具体使用哪种方案还是需要不同的业务特点自行选择。分布式事务提高了流程的复杂度，带来很多额外的开销工作，代码量上去了，业务复杂了，性能下跌了。所以，真实开发的过程中，能不使用分布式事务就不使用。

sentinel(哨兵机制)：是 Redis 中集群的高可用方式，哨兵节点是特殊的 Redis 服务，不提供读写，主要来监控 Redis 中的实例节点，如果监控服务的主服务器下线了，会从所属的从服务器中重新选出一个主服务器，代替原来的主服务器提供服务。当然这个数值在 Redis 中是可以配置的。对于主从集群模式，如果从库发生了故障，还有主库和其它的从库可以接收请求，但是如果主库挂了，就不能进行正常的数据写入，同时数据同步也不能正常的进行了，当然这种情况，我们需要想办法避免，于是就引入了下面的哨兵机制。

数据库事务在实现时会将一次事务涉及的所有操作全部纳入到一个不可分割的执行单元，该执行单元中的所有操作要么都成功，要么都失败，只要其中任一操作执行失败，都将导致整个事务的回滚。RM：Resource Manager 资源管理器，用于分支事务上的资源管理，向TC注册分支事务，上报分支事务的状态，接受TC的命令来提交或者回滚分支事务。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

Docker容器的运行逻辑如下图所示，Docker使用客户端/服务器 (C/S) 架构模式，Docker守护进程（Docker daemon）作为Server端接收Docker客户端的请求，并负责创建、运行和分发Docker容器。Docker守护进程一般在Docker主机后台运行，用户使用Docker客户端直接跟Docker守护进程进行信息交互。Docker守护进程：接收并处理Docker客户端发送的请求，监测Docker API的请求和管理Docker对象，比如镜像、容器、网络和数据卷。