一、问题抛出 在做查询语句时，MySQL 抛出了这样的异常： MySQL server error report:Array ( [0] => Array ( [message] => MySQL Query Error ) [1] => Array ( [sql] => SELECT * FROM taobao_trade WHERE order_status = 1 and orderID ='2018061812306547' AND is_tran_success=0 for update ) [2] => Array ( [error] => Lock wait timeout exceeded; try restarting transaction ) [3] => Array ( [errno] => 1205 ) ) 即Lock wait timeout exceeded; try restarting transaction的异常，错误提示的意思，很明显，是因为这条语句被锁住了，所以释放这个锁。 二、解决方案 我们可以通过到information_schema 中来进行查找被锁的语句。 解释：information_schema这张数据表保存了MySQL服务器所有数据库的信息。如数据库名，数据库的表，表栏的数据类型与访问权限等。再简单点，这台MySQL服务器上，到底有哪些数据库、各个数据库有哪些表，每张表的字段类型是什么，各个数据库要什么权限才能访问，等等信息都保存在information_schema表里面。 我们可以用下面三张表来查原因： innodb_trx 当前运行的所有事务 innodb_locks 当前出现的锁 innodb_lock_waits 锁等待的对应关系 如果数据库中有锁的话，我们可以使用这条语句来查看： select * from information_schema.innodb_trx 图中红色语句 LOCK WAIT为占用系统资源的语句，我们需要杀掉这个锁，执行 kill 线程id号。上面这条记录的id为199120823069, trx_mysql_thread_id 为 738178711, 所以我们执行：kill 738178711杀掉这个MySQL语句的线程即可。 执行之后： kill 738178711 // 查询线程 // SELECT * from information_schema.processlist WHERE id = 738178711; // show full processlist; 其他的记录不需要关注，因为其他的记录状态为“RUNNING” 即正在执行的事务，并没有锁。 三、三张表字段说明 innodb_trx desc information_schema.innodb_trx; innodb_locks desc information_schema.innodb_locks; innodb_lock_waits desc information_schema.innodb_lock_waits 四、终极方法 如果以上方法杀掉线程，但还是不能解决，则我们就可以查找执行线程用时比较久的用户，然后直接干掉。 SELECT * from information_schema.`PROCESSLIST` WHERE Time >

什么是Camel？ Camel框架的核心是一个路由引擎，或者更确切地说是一个路由引擎构建器。它允许您定义自己的路由规则，决定从哪个源接收消息，并确定如何处理这些消息并将其发送到其他目标。 Camel提供更高层次的抽象，使您可以使用相同的API与各种系统进行交互，而不管系统使用的协议或数据类型如何。 Camel中的组件提供了针对不同协议和数据类型的API的特定实现。开箱即用，Camel支持80多种协议和数据类型。 Getting started 源码地址：https://github.com/camelinaction/camelinaction.git 下面是一个拷贝文件的例子，将文件从data/inbox拷贝到data/outbox 1 添加maven依赖 <dependencies> <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-core</artifactId> <version>2.15.6</version> </dependency> </dependencies> 2 代码 public class FileCopierWithCamel { public static void main(String args[]) throws Exception { // create CamelContext CamelContext context = new DefaultCamelContext(); // add our route to the CamelContext context.addRoutes(new RouteBuilder() { public void configure() { /** file: 表示使用文件Component from 表示从哪里获取数据，进行消费 to 表示将数据生产到哪里 */ from("file:data/inbox?noop=true").to("file:data/outbox"); } }); // start the route and let it do its work context.start(); Thread.sleep(10000); // stop the CamelContext context.stop(); } } Camel概念 CamelContext Camel的容器，通过CamelContext可以访问内部服务：Components，Endpoints，Endpoints，Registry等等 image.png Routes 通过路由可以实现：客户端与服务端，生产者与消费者的解耦 比如：从ftp服务上获取订单信息，将其发送到JMS队列，可以通过如下路由表示 //from可以理解成消费者：表示从ftp服务上获取数据进行消费 from("ftp://rider.com/orders?username=rider&password=secret") //to可以理解成生产者：表示将数据发送给jms .to("jms:incomingOrders"); image.png endpoint URI 可以简单理解成消息的地址 对

这是一道频繁出现的题目，个人认为也是一道很好的题目，这题纵深非常深，内行的人可以讲的非常深。 首先讲两个术语，数据库和存储引擎。数据库往往是一个比较丰富完整的系统, 提供了SQL查询语言，事务和水平扩展等支持。然而存储引擎则是小而精, 纯粹专注于单机的读/写/存储。一般来说, 数据库底层往往会使用某种存储引擎。 目前开源的KV存储引擎中，RocksDB是流行的一个，MongoDB和MySQL底层可以切换成RocksDB， TiDB底层直接使用了RocksDB。大多数分布式数据库的底层不约而同的都选择了RocksDB。 RocksDB最初是从LevelDB进化而来的，我们先从简单一点的LevelDB入手，借鉴它的设计思路。 LevelDB整体结构 有一个反直觉的事情是，内存随机写甚至比硬盘的顺序读还要慢，磁盘随机写就更慢了，说明我们要避免随机写，最好设计成顺序写。因此好的KV存储引擎，都在尽量避免更新操作，把更新和删除操作转化为顺序写操作。LevelDB采用了一种SSTable的数据结构来达到这个目的。 SSTable(Sorted String Table)就是一组按照key排序好的 key-value对, key和value都是字节数组。SSTable既可以在内存中，也可以在硬盘中。SSTable底层使用LSM Tree(Log-Structured Merge Tree)来存放有序的key-value对。 LevelDB整体由如下几个组成部分， MemTable。即内存中的SSTable，新数据会写入到这里，然后批量写入磁盘，以此提高写的吞吐量。 Log文件。写MemTable前会写Log文件，即用WAL(Write Ahead Log)方式记录日志，如果机器突然掉电，内存中的MemTable丢失了，还可以通过日志恢复数据。WAL日志是很多传统数据库例如MySQL采用的技术，详细解释可以参考数据库如何用 WAL 保证事务一致性？ - 知乎专栏。 Immutable MemTable。内存中的MemTable达到指定的大小后，将不再接收新数据，同时会有新的MemTable产生，新数据写入到这个新的MemTable里，Immutable MemTable随后会写入硬盘，变成一个SST文件。 SSTable文件。即硬盘上的SSTable，文件尾部追加了一块索引，记录key->offset，提高随机读的效率。SST文件为Level 0到Level N多层，每一层包含多个SST文件；单个SST文件容量随层次增加成倍增长；Level0的SST文件由Immutable MemTable直接Dump产生，其他Level的SST文件由其上一层的文件和本层文件归并产生。 Manifest文件。 Manifest文件中记录SST文件在不同Level的分布，单个SST文件的最大最小key，以及其他一些LevelDB需要的元信息。 Current文件。从上面的介绍可以看出，Lev

从MySQL5.5开始，MySQL以插件的形式支持半同步复制。如何理解半同步呢？首先我们来看看异步，全同步的概念 异步复制（Asynchronous replication） MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。 全同步复制（Fully synchronous replication） 指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。 半同步复制（Semisynchronous replication） 介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。 下面来看看半同步复制的原理图： 半同步复制的潜在问题 客户端事务在存储引擎层提交后，在得到从库确认的过程中，主库宕机了，此时，可能的情况有两种 事务还没发送到从库上 此时，客户端会收到事务提交失败的信息，客户端会重新提交该事务到新的主上，当宕机的主库重新启动后，以从库的身份重新加入到该主从结构中，会发现，该事务在从库中被提交了两次，一次是之前作为主的时候，一次是被新主同步过来的。 事务已经发送到从库上 此时，从库已经收到并应用了该事务，但是客户端仍然会收到事务提交失败的信息，重新提交该事务到新的主上。 无数据丢失的半同步复制 针对上述潜在问题，MySQL 5.7引入了一种新的半同步方案：Loss-Less半同步复制。 针对上面这个图，“Waiting Slave dump”被调整到“Storage Commit”之前。 当然，之前的半同步方案同样支持，MySQL 5.7.2引入了一个新的参数进行控制-rpl_semi_sync_master_wait_point rpl_semi_sync_master_wait_point有两种取值 AFTER_SYNC 这个即新的半同步方案，Waiting Slave dump在Storage Commit之前。 AFTER_COMMIT 老的半同步方案，如图所示。 半同步复制的安装部署 要想使用半同步复制，必须满足以下几个条件： 1. MySQL 5.5及以上版本 2. 变量have_dynamic_loading为YES 3. 异步复制已经存在 首先加载插件

Sandboxie-Plus 是什么 官网：https://sandboxie-plus.com/ GitHub：https://github.com/sandboxie-plus Sandboxie 是一款最早发布于 2004 年的老牌 Windows 沙盒软件，它可以创建一个隔离环境，在其中安装、运行程序而不影响沙盒外的文件。2020 年起，Sandboxie 转交开源社区维护。 Sandboxie-Plus 是开源社区基于 Sandboxie 开发的增强版本，拥有基于 Qt 的现代 UI 和开源后添加的所有新功能。Sandboxie-Plus 可以创建多个沙盒，可以为每个沙盒提供快照管理器、精细的文件系统控制、权限控制和网络访问控制。可以对沙盒内程序限制网络访问、限制资源访问(文件、注册表等)、限制提权、阻止访问剪贴板等。 Sandboxie-Plus 的第一个 1.0 稳定版发布于 2021 年 12 月 25 日，目前还在积极开发中。经笔者测试，目前的最新版 1.0.7 在 Windows 10 和 Windows 11 下都能正常使用，在 GitHub 上反馈的问题基本都能得到响应和修复。得益于热心的贡献者，UI 上的大部分元素都有中文翻译。 快速入门 Sandboxie-Plus (非便携模式) 默认将沙盘配置文件存放在 C:\Windows\Sandboxie.ini，备份此文件即可备份所有沙盘的配置。沙盘文件目录在 C:\Sandbox\[当前用户名]\[沙盘名] 中，在此路径下双击打开任何软件都将强制在沙盘中打开。沙盘中程序创建、修改的注册表位于 HKEY_USERS\Sandbox_[当前用户名]_[沙盘名] 中。当然，这些路径都可以在「设置-高级选项」中修改。 安装完成后还可以可选的在文件资源管理器右键菜单中添加「在沙盘中运行」项，方便使用。注意，这个文件必须要在你选择的沙盘中可读取，否则沙盘会报错。 在沙盘中运行程序与直接运行几乎没有区别，默认情况下在标题会有 [#] 标记，以及在鼠标移到标题时显示黄色边框，这些外观样式都可以在对应沙盘选项中修改。 ⚠️警告：不要认为隔离是100%的，即使虚拟机都存在被逃逸的可能，追求完美请使用物理方法隔离，不要尝试在沙盘中测试病毒！ 沙盒模板简单介绍 部分功能需要捐赠，详见下方「捐赠获得支持者凭证(Supporter Certificate)」 Sandboxie-Plus 默认的 DefaultBox 即为标准隔离沙盒。这个沙盒模板默认不限制对所有文件的读取，但沙盒内程序无法写入、修改、删除沙盒外的文件、注册表。在沙盒内创建的文件会被重定向到该沙盒目录中，修改文件会在沙盒目录中创建一个副本进行修改，删除文件会在沙盒目录中建立一个对应的0字节文件。 安全防护加固型沙盒是在标准隔离沙盒的基础上，加上勾选「常