1. 前言 Thrift是Facebook贡献给apache的rpc框架，但是这款框架的java版本在公司内部并不是那么受待见，因为其性能相比C++版本差了很多，但是后续基于netty重写了以后性能得到了极大的提升，相比于C++版本已经差距不大了。为此取了个新的名字Nifty = Netty + Thrift。 如果你使用过thrift的话，基本都会使用自动生成的代码，那真的是没法看，即使定义一个简单的类都会生成巨多的代码，把read，write方法全部写到里面去了。总之早期的thrfit各方面都似乎不那么友好。后面架构进行了升级，提供了新的swift库，注意这个不是ios的swift，从而生成的java类和普通的java类基本一致，无非多了点注解，而序列化反序列化也都移到了相应的包中，从而...阅读全文
本文概括性的介绍gRPC，包括gRPC的起源，核心特性，生态体系，以及一些知名开源软件对gRPC的使用，最后总结gRPC与netty、dubbo等框架的区别，目的是让读者从整体上对gRPC有一个相对全面的认知。1 gRPC起源十多年来，Google一直在使用一个名为Stubby的通用RPC基础架构来连接在数据中心内部和跨越数据中心运行的大量微服务，其内部系统长期以来一直接受微服务架构的普及。拥有统一的跨平台RPC基础架构，可以在整个系统范围内推广效率，安全性，可靠性和行为分析，这对于支持Google的惊人增长至关重要。我们今天使用的每个Google服务背后的RPC骨干都是Stubby。Stubby有许多很棒的功能 - 但是，它不是基于任何标准，而是与Google的内部基础设施紧密耦合，并不适...阅读全文
一次偶然事件，我检查某台服务器系统时发现一个从来没见过的端口处于监听（LISTEN）状态，于是开始仔细检查系统。 [root@db097 ~]# netstat -lnpt | grep 7979 tcp 0 0 0.0.0.0:7979 0.0.0.0:* LISTEN - 进程里什么都没有，试了多种办法试着去找一下，都是一样的结果。 [root@db097 ~]# lsof -i:7979 google了半天，最后一段话提示了我： I realized it’s an port opened by kernel, that’s why it won’t show up with program name. For the port like this, it may relate to ...阅读全文
在Hbase中split是一个很重要的功能，Hbase是通过把数据分配到一定数量的region来达到负载均衡的。一个table会被分配到一个或多个region中，这些region会被分配到一个或者多个regionServer中。在自动split策略中，当一个region达到一定的大小就会自动split成两个region。table在region中是按照row key来排序的，并且一个row key所对应的行只会存储在一个region中，这一点保证了Hbase的强一致性 。 在一个region中有一个或多个stroe，每个stroe对应一个column families(列族)。一个store中包含一个memstore 和 0 或 多个store files。每个column family 是...阅读全文
HBase基于LSM模式，写是写HLOG及Memory的，也就是基本没有随机的IO，所以在写链路上性能高效还比较平稳。很多时候，写都是用可靠性来换取性能。 批量写 也是为了减少rpc的次数HTable.put(List
1 简介 刚开始接触 Kubernetes 时，你学到的第一件事就是每个 Pod 都有一个唯一的 IP 和主机名，并且在同一个 Pod 中，容器可以通过 localhost 相互通信。所以，显而易见，一个 Pod 就像一个微型的服务器。 但是，过段时间，你会发现 Pod 中的每个容器都有一个隔离的文件系统，并且从一个容器内部，你看不到在同一 Pod 的其他容器中运行的进程。好吧！也许 Pod 不是一个微型的服务器，而只是一组具有共享网络堆栈的容器。 但随后你会了解到，Pod 中的容器可以通过共享内存进行通信！所以，在容器之间，网络命名空间不是唯一可以共享的东西……基于最后的发现，所以，我决定深入了解： Pod 是如何在底层实现的 Pod 和 Container 之间的实际区别是什么 如何使用...阅读全文
一、HBase 读优化 1. HBase客户端优化 和大多数系统一样，客户端作为业务读写的入口，姿势使用不正确通常会导致本业务读延迟较高实际上存在一些使用姿势的推荐用法，这里一般需要关注四个问题： 1) scan缓存是否设置合理？ 优化原理：在解释这个问题之前，首先需要解释什么是scan缓存，通常来讲一次scan会返回大量数据，因此客户端发起一次scan请求，实际并不会一次就将所有数据加载到本地，而是分成多次RPC请求进行加载，这样设计一方面是因为大量数据请求可能会导致网络带宽严重消耗进而影响其他业务，另一方面也有可能因为数据量太大导致本地客户端发生OOM。在这样的设计体系下用户会首先加载一部分数据到本地，然后遍历处理，再加载下一部分数据到本地处理，如此往复，直至所有数据都加载完成。数据加载...阅读全文
