JSON

和其他一些语言不同，Java 没有对 JSON 的原生支持（first class support），因此我们提供了两个类，以便在 Vert.x 应用中处理 JSON 更容易。

JSON 对象

JsonObject 类用来描述JSON对象。

一个JSON 对象基本上只是一个 Map 结构。它具有字符串的键，值可以是任意一种JSON 支持的类型（如 string, number, boolean）。

JSON 对象也支持 null 值。

Event Bus

Event Bus 是 Vert.x 的神经系统。

每一个 Vert.x 实例都有一个单独的 Event Bus 实例。您可以通过 Vertx 实例的eventBus方法来获得对应的EventBus 实例。

您的应用中的不同部分通过 Event Bus 相互通信，无论它们使用哪一种语言实现，无论它们在同一个 Vert.x 实例中或在不同的 Vert.x 实例中。

甚至可以通过桥接的方式允许在浏览器中运行的客户端JavaScript在相同的Event Bus上相互通信。

Event Bus可形成跨越多个服务器节点和多个浏览器的点对点的分布式消息系统。

Event Bus支持发布/订阅、点对点、请求/响应的消息通信方式。

Event Bus的API很简单。基本上只涉及注册处理器、撤销处理器和发送和发布消息。

首先来看些基本概念和理论。

在 Vert.x 中，想要延迟之后执行或定期执行操作很常见。

在 Standard Verticle 中您不能直接让线程休眠以引入延迟，因为它会阻塞 Event Loop 线程。取而代之是使用 Vert.x 定时器。定时器可以是一次性或周期性的，两者我们都会讨论到。

Context 对象

当 Vert.x 传递一个事件给处理器或者调用 Verticle 的 start 或 stop 方法时，它会关联一个Context对象来执行。通常来说这个 Context 会是一个 Event Loop Context，它绑定到了一个特定的 Event Loop 线程上。所以在该 Context 上执行的操作总是在同一个 Event Loop 线程中。对于运行内联的阻塞代码的 Worker Verticle 来说，会关联一个 Worker Context，并且所有的操作运都会运行在 Worker 线程池的线程上。

译者注：每个 Verticle 在部署的时候都会被分配一个 Context（根据配置不同，可以是Event Loop Context 或者 Worker Context），之后此 Verticle 上所有的普通代码都会在此 Context 上执行（即对应的 Event Loop 或Worker 线程）。一个 Context 对应一个 Event Loop 线程（或 Worker 线程），但一个 Event Loop 可能对应多个 Context。

什么是Verticle ？

Vert.x 通过开箱即用的方式提供了一个简单便捷的、可扩展的、类似 Actor Model 的部署和并发模型机制。您可以用此模型机制来保管您自己的代码组件。

这个模型是可选的，如果您不想这样做，Vert.x 不会强迫您用这种方式创建您的应用程序。

这个模型不能说是严格的 Actor 模式的实现，但它确实有相似之处，特别是在并发、扩展性和部署等方面。

要使用该模型，您需要将您的代码组织成一系列的 Verticle。

Verticle 是由 Vert.x 部署和运行的代码块。默认情况一个 Vert.x 实例维护了N（默认情况下N = CPU核数 x 2）个 Event Loop 线程。Verticle 实例可使用任意 Vert.x 支持的编程语言编写，而且一个简单的应用程序也可以包含多种语言编写的 Verticle。

您可以将 Verticle 想成 Actor Model 中的 Actor。

一个应用程序通常是由在同一个 Vert.x 实例中同时运行的许多 Verticle 实例组合而成。不同的 Verticle 实例通过向 Event Bus 上发送消息来相互通信。

vert.x 是什么？

Vert.x是一个基于JVM、轻量级、高性能的应用平台。基于它可开发各种移动，Web和企业应用程序。一个主要特点是可使用多种语言编写应用，如Java, JavaScript, CoffeeScript, Ruby, Python 或 Groovy等等，它的简单actor-like机制能帮助脱离直接基于多线程编程。它是基于Netty和Java 7的NIO2的编写的。

vert.x hello world

maven依赖：

1
2
3
4
5

<dependency>
  <groupId>io.vertx</groupId>
  <artifactId>vertx-core</artifactId>
  <version>${vertx.version}</version>
</dependency>

背景

在工作中经常会遇到一些非常有用的SQL，记录下来以备不时之需。

查看数据库大小

1
2
3

select concat(round(sum(data_length) /1024/1024/1024, 2), 'GB') as '数据大小', concat(round(sum(index_length) /1024/1024/1024, 2), 'GB') as '索引大小' 
from information_schema.tables 
where table_schema = 'test';

查看数据库每个表的大小

1
2
3
4

select table_name, concat(round(data_length /1024/1024/1024, 2), 'GB') as 'table_size', concat(round(index_length /1024/1024/1024, 2), 'GB') as 'index_size' 
from information_schema.tables 
where table_schema = 'test'
order by table_size desc;

背景

用了好多年maven了，在使用中遇到好多问题，虽然一一解决了，但是并没有详细总结归纳形成最佳实践。通过这篇文章将使用中遇到过的问题一一记录，以后再次遇到同类问题就不用再Google了。

maven坐标

maven的世界里有海量的构件，如何查找需要的构件是非常重要的事情。maven通过称为坐标的概念来定位仓库中的构件。maven构件的坐标有一下几个元素：

• groupId 构件所属的项目
• artifactId 构件所在的模块。
• version 构件的版本号
• packaging 构件打包的类型，默认是jar
• classifier 构件使用的JDK版本

背景

在项目中发现有大量的查询方法设置了@Transactional(readOnly=true)，印象中也了解到数据库会对只读事务做一些优化，但并没有升入的了解具体是如何实现的，应用中该如何使用只读事务。这篇文章就对只读事务做一个分析总结。

autocommit

在分析只读事务前很有必要提一下autocommit。MySQL默认对每一个新建立的连接都启用了autocommit模式。在该模式下，每一个发送到MySQL服务器的sql语句都会在一个单独的事务中进行处理，执行结束后会自动提交事务，并开启一个新的事务。具体可以参考innodb-autocommit-commit-rollback。

只读事务

A type of transaction that can be optimized for InnoDB tables by eliminating some of the bookkeeping involved with creating a read view for each transaction. Can only perform non-locking read queries. It can be started explicitly with the syntax START TRANSACTION READ ONLY, or automatically under certain conditions. See Section 8.5.3, “Optimizing InnoDB Read-Only Transactions” for details.

只读事务是事务的一种，可以用来优化InnoDB表上查询事务创建的效率，并可以提供非锁定查询的性能。

InnoDB引擎有一下两种方式来检测一个事务是否是只读事务。

1. 通过START TRANSACTION READ ONLY语句来检测。
   在该事务中如果有对数据库的修改操作(InnoDB, MyISAM, 或其它类型的数据库表)，那么将会产生一个错误，并且事务会继续以只读事务进行。
   但是在只读事务中，你可以对session级别的临时表进行操作，又或者执行一个锁定查询。这是因为这些修改操作和加锁操作对其它事务是不可见的。
2. 打开autocommit设置，此时事务确保只有一个SQL语句被执行，并且事务中的语句是一个非锁定查询的语句。非锁定查询的语句指的是不使用FOR UPDATE 或 LOCK IN SHARED MODE限制的查询语句。

这样，针对报表生成这类查询比较集中的应用，你可以将一些查询语句组合起来放在一个START TRANSACTION READ ONLY 和 COMMIT语句中间，或者在执行查询语句前打开autocommit设置，又或者避免在事务中的多个语句中包含导致数据变化的语句。

只读事务的优化

InnoDB can avoid the overhead associated with setting up the transaction ID (TRX_ID field) for transactions that are known to be read-only. A transaction ID is only needed for a transaction that might perform write operations or locking reads such as SELECT … FOR UPDATE. Eliminating unnecessary transaction IDs reduces the size of internal data structures that are consulted each time a query or data change statement constructs a read view.

参考

glos_read_only_transaction

背景

今天一个同事在服务器上修改了/etc/hosts文件，将一个远程的域名解析到了本机remote.host.name 127.0.0.1。此时一切正常，所有请求都路由到了本机。但是将/etc/hosts文件中的配置删除后，域名还是解析到本机。此时很容易想到是DNS缓存。只要清除了DNS缓存就好了。Google了一下，发现好多文章都没有解决我的问题。最终找到此篇文章：How to Clear/flush DNS Cache on Linux，总算解决了问题。算是有学习到一点知识。

将本篇文章翻译如下，让更多需要的同学查看。