innodb_flush_log_at_trx_commit 和 sync_binlog 是 MySQL 的两个配置参数，前者是 InnoDB 引擎特有的。之所以把这两个参数放在一起讨论，是因为在实际应用中，它们的配置对于 MySQL 的性能有很大影响。 1. innodb_flush_log_at_trx_commit简而言之，innodb_flush_log_at_trx_commit 参数指

分区表有什么问题，为什么公司规范不让使用分区表呢？ 分区表是什么？为了说明分区表的组织形式，我先创建一个表 t： 1234567891011CREATE TABLE `t` ( `ftime` datetime NOT NULL, `c` int(11) DEFAULT NULL, KEY (`ftime`)) ENGINE=InnoDB DEFAULT CHARSET=latin1PAR

所谓的副本机制（Replication），也可以称之为备份机制，通常是指分布式系统在多台网络互联的机器上保存有相同的数据拷贝。副本机制有什么好处呢？ 提供数据冗余。即使系统部分组件失效，系统依然能够继续运转，因而增加了整体可用性以及数据持久性。 提供高伸缩性。支持横向扩展，能够通过增加机器的方式来提升读性能，进而提高读操作吞吐量。 改善数据局部性。允许将数据放入与用户地理位置相近的地方，从而降低

Kafka部分名词解释如下： Broker：消息中间件处理结点，一个Kafka节点就是一个broker，多个broker可以组成一个Kafka集群。 Topic：一类消息，例如page view日志、click日志等都可以以topic的形式存在，Kafka集群能够同时负责多个topic的分发。 Partition：topic物理上的分组，一个topic可以分为多个partition，每个part

Kafka 单个节点的极限处理能力接近每秒钟 2000 万条消息，吞吐量达到每秒钟 600MB。 那kafka是如何做到的呢？    1. 分区  生产者往Kafka发送消息时必须指定发往哪个主题，消费者需要订阅某个主题才能进行消费。一个主题下的分区可以分布在集群的不同broker上面，也就是说，一个主题可以横跨多个broker。这样的话，生产者在指定主题（可以指定也可以不指定分区）发送消息的时候

MySQL 主备的基本原理 主备流程图 主库接收到客户端的更新请求后，执行内部事务的更新逻辑，同时写 binlog。 备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程，专门用于服务备库 B 的这个长连接。一个事务日志同步的完整过程是这样的： 在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog

InnoDB 是如何存储数据的？ MySQL 支持多种存储引擎，不同的存储引擎，存储数据的方式也是不同的，最常使用的是 InnoDB 存储引擎。 记录是按照行来存储的，但是数据库的读取并不以「行」为单位，否则一次读取（也就是一次 I/O 操作）只能处理一行数据，效率会非常低。 因此，InnoDB 的数据是按「数据页」为单位来读写的，也就是说，当需要读一条记录的时候，并不是将这个记录本身从

AQS 用法 JDK 里利用 AQS 类的主要步骤： 第一步，新建一个自己的线程协作工具类，在内部写一个 Sync 类，该 Sync 类继承 AbstractQueuedSynchronizer，即 AQS； 第二步，想好设计的线程协作工具类的协作逻辑，在 Sync 类里，根据是否是独占，来重写对应的方法。如果是独占，则重写 tryAcquire 和 tryRelease 等方法；如果是非独占，

如何实现 MySQL 的读写分离？其实很简单，就是基于主从复制架构，简单来说，就搞一个主库，挂多个从库，然后我们就单单只是写主库，然后主库会自动把数据给同步到从库上去。 MySQL 主从复制原理的是啥？MySQL的复制原理概述上来讲大体可以分为这三步 在主库上把数据更改，记录到二进制日志（Binary Log）中。 从库将主库上的日志复制到自己的中继日志（Relay Log）中。 备库读取中继日

Kafka 只对“已提交”的消息（committed message）做有限度的持久化保证。 第一个核心要素是“已提交的消息”。什么是已提交的消息？当 Kafka 的若干个 Broker 成功地接收到一条消息并写入到日志文件后，它们会告诉生产者程序这条消息已成功提交。此时，这条消息在 Kafka 看来就正式变为“已提交”消息了。 那为什么是若干个 Broker 呢？这取决于对“已提交”的定义。可以