ITPub博客

2011 年 10 月 27 日，阿里巴巴开源了自己服务化治理方案的核心框架 Dubbo，服务治理的设计理念开始逐渐在国内软件行业中落地，并被广泛应用。自开源后，许多非阿里系公司选择使用 Dubbo，其中既有当当网、网易考拉等互联网公司，也有中国人寿、青岛海尔等传统企业。

最近有朋友问我这么一个面试题目：现在有一个非常庞大的数据，假设全是 int 类型。现在我给你一个数，你需要告诉我它是否存在其中(尽量高效)。

我们已经聊过了 TCP 中的 KeepAlive，以及在应用层设计心跳的意义，但却对长连接心跳的设计方案没有做详细地介绍。事实上，设计一个好的心跳机制并不是一件容易的事，就我所熟知的几个 RPC 框架，它们的心跳机制可以说大相径庭，这篇文章我将探讨一下如何设计一个优雅的心跳机制，主要从 Dubbo 的现有方案以及一个改进方案来做分析。

可能很多 Java 程序员对 TCP 的理解只有一个三次握手，四次挥手的认识，我觉得这样的原因主要在于 TCP 协议本身稍微有点抽象（相比较于应用层的 HTTP 协议）；其次，非框架开发者不太需要接触到 TCP 的一些细节。其实我个人对 TCP 的很多细节也并没有完全理解，这篇文章主要针对微信交流群里有人提出的长连接，心跳的问题，做一个统一的整理。

在不谈及 dubbo 时，我们中的大多数人对 URL 这个概念并不会感到陌生。统一资源定位器 (RFC1738――Uniform Resource Locators (URL)）应该是最广为人知的一个 RFC 规范，它的定义也非常简单

dubbo功能非常完善，很多时候我们不需要重复造轮子，下面列举一些你不一定知道，但是很好用的功能。在开发及测试环境下，可能需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直连模式，将以服务接口为单位，忽略注册中心的提供者列表，A 接口配置点对点，不影响 B 接口从注册中心获取列表（说明：官方只建议开发&测试环境使用该功能），用法如下，url指定的地址就是直连地址：

到了年底果然都不太平，最近又收到了运维报警：表示有些服务器负载非常高，让我们定位问题。还真是想什么来什么，前些天还故意把某些服务器的负载提高（没错，老板让我写个 BUG！），不过还好是不同的环境互相没有影响。

国际惯例，先报成绩，熬了无数个夜晚，最后依旧被绝杀出了第一页，最终排名第 21 名。前十名的成绩分布为 413.69~416.94，我最终的耗时是 422.43。成绩虽然不是特别亮眼，但与众多参赛选手使用 C++ 作为参赛语言不同，我使用的是 Java，一方面是我 C++ 的能力早已荒废，另一方面是我想验证一下使用 Java 编写存储引擎是否与 C++ 差距巨大(当然，主要还是前者 QAQ)。所以在本文中，我除了介绍整体的架构之外，还会着重笔墨来探讨 Java 编写存储类型应用的一些最佳实践，文末会给出 github 的开源地址。

一个小白程序员的成长之路，你可以在这里看到我的原创文章，杂谈，以及优秀的技术文章转载。

上一篇文章《Spring Security(二)--Guides》，通过Spring Security的配置项了解了Spring Security是如何保护我们的应用的，本篇文章对上一次的配置做一个分析。

如果让你在本地构建一个 Dubbo 应用，你会需要额外搭建哪些中间件呢？如果没猜错的话，你的第一反应应该是注册中心，类 Dubbo 的大多数服务治理框架都有注册中心的概念。你可以部署一个 Zookeeper，或者一个 Nacos，看你的喜好。但在 Apache Dubbo 的 2.7 版本后，额外引入了两个中间件：元数据中心和配置中心。

Dubbo 线程池满异常应该是大多数 Dubbo 用户都遇到过的一个问题，本文以 Arthas 3.1.7 版本为例，介绍如何针对该异常进行诊断，主要使用到 dashboard/thread 两个指令。

近日，备受瞩目的 Apache Dubbo（以下简称 Dubbo）2.7.5 版本正式发布，在 2.7.5 版本中，Dubbo 引入了很多新的特性、对现有的很多功能做了增强、同时在性能上也有了非常大的提升，这个版本无论对 Dubbo 社区亦或是开发者来说，都将是一个里程碑式的版本。

上周四晚刚回到家，就接到了软负载同学的电话，说是客户线上出了故障，我一听”故障“两个字，立马追问是什么情况，经过整理，还原出线上问题的原貌：