大数据架构之道

我们查询服务所遇到过高可用的问题。当出现大量并发请求，就会导致服务不可用。所以，一个系统，首先必须要做到高可用。

现在的系统架构时代，早已不是当年那个“不行就加机器”的时代了。因为现在上网的越来越多，数据产生越来越大，流量越来越大。不行就加机器，成本实在是太高了。

一直对腾讯做产品的能力比较敬佩的，我们组做消息推送系统，而腾讯的信鸽就是我们学习的榜样。京东很多做产品的思想是跟腾讯学的，而京东很多同事也从腾讯过来的(京东合并了腾讯电商)，耳濡目染学到很多东西。

新搭建的HBase，没有任何表，web-ui上不显示hbase系统表。过一会儿退出master。

Flink运行过程是Flink引擎的核心部分，支撑着Flink流作业和批作业的运行，同时保障作业的高可用和可扩展性等。Flink运行时采用Master-Worker的架构，其中Flink的Master节点为JobManager，Worker节点为TaskManager。

频繁高并发请求导致服务响应变慢、出现假死，直至OOM后重启。是什么原因引起的呢？

使用Flink已有三年，虽然在我们真实的业务场景下，使用到Flink的特性并不多，但不能代表未来不会使用到其它的特性。为了保证自己的知识库，所以打算写一下Flink相关的总结，以便日后翻阅。

本篇是基于ClusterReplication的理论基础，进行实践。理论基础请参考前文：

HBase提供了一种集群复制机制。它通过传播WAL文件来保证多集群之间状态互相同步。一般情况下，这种ClusterReplication机制用于：

由于某些业务场景，Redis中的单个Key下的Value是一个很大的值，这些bigkey对我们的查询会有多大影响呢？