fpcc的专栏

一、哨兵Sentinel（哨兵），听名字大家都应该想得到这个家伙是做什么的。在redis的应用中，有单机模式、主从模式、哨兵模式和集群模式，其实你从它的发展就可以看出来，redis是从一个简单的应用开始，不断的壮大，从单点到分布式，从简单的主从备份以及初始的哨兵监控，再到可以看成把二者合成的集群模式，除了是应用场景的变化，更多的是为了提高安全性和高可用性。网上有很多人问哨兵和集群有啥不一样，其实你从REDIS的发展角度去看问题，自然就明白了这个道理。这也是后来者学习一些东西的悲哀之处，虽然直接用到...

一、复制在Redis中， 前面提到了为了安全保证，要有主从复制，分布式部署等等。在前面的分析中，更多的是倾向于网络的同步过程，这次重点分析一下复制的过程。这一部分的代码在replication.c中。复制的功能主要有两部分，即全量复制和同步复制。实现复制的方法主要有以下几种：1、通过配置文件建立主从关系，从而引起复制。2、使用命令启动复制。3、使用命令直接复制。需要注意的是，在集群模式下，主从复制是无法进行的，看代码的时候儿会有判断（集群使用的不同的方式————槽SLOT的迁移或者说键K...

一、通知在Redis中，既可以实现消息的发送又可以实现订阅，也就是常说的发布/订阅。它的主要逻辑实现在nofigy.c和module.c、pubsub.c中，其实通知做为一种辅助功能，是易用性的一种良好的接口。Redis的通知功能是一种即时在线通知功能，如果CS端断线后，相关的消息就无法再次通知，也就是说，消息机制没有保存和重发功能。这也是为了实现设计上的简单和功能实现的鲁棒性的考虑，至于以后会不会继续修改，还得看应用的需求。为了效率和开销，REDIS默认是关闭通知的，可以理解，能玩儿REDIS...

一、慢查询慢查询其实说法是Redist在实际应用中对超过时间阈值（默认10ms）的查询进行日志保存。之所以对这个命令进行一个单独的分析，主要这是对REIDS的效率的分析有重要的作用。在Redis中，一条命令的查询从发送到执行，直到返回结果，其中都要耗费时间，但是在redis的统计过程中，只统计执行的时间。也就是说，慢查询一定是执行的过程太慢。影响慢查询设置的有两个参数：slowlog-log-slower-than 慢查询阈值（微秒）slowlog-max-len 慢查询日志数量这两个参数既可以通

一、集群再强大的系统也有当机的时候，可能是自身原因，也可能是外在原因。那么单机部署任何一个软件，都会有这种风险，而有的时候儿，这种风险是不可承受的或者说成本太高了。所以，支持分布式的部署几乎是所有大型软件的必备，Redis同样也支持，这就是集群模式。Redis的分布式集群模式不是一步而就的，一开始是简单的主从模式，一主N备，发现主设备挂掉，需要人工参与将Slaver提升到主；后来在2.8版本中，增加了哨兵模式，也就是简单化了主从的转化，但仍然没有解决主从模式中从节点下线的人工干预，也无法进行自动...

一、网络的整体架构在前面介绍Redis的整体流程时，初步介绍过服务端的网络代码，现在先看一下整体的架构：1、服务处理（EPoll）如果没有接触过网张编程的，特别是对LINUX上的编程模型一点都不清楚的。这块可能是个麻烦.Redis为了保证在不两同的平台的高效可行的运行，采用了在不同平台自适应使用不同的网络编程模型，这其中包括一些可能比较专用的平台，如Solaries10中的 evport，macos(FreeBSD)中的Kqueue模型。一般情况下，不论是类UNIX平台还是类LINUX平台，都...

一、ziplist压缩列表压缩列表是HASH和跳表的小数据时的数据结构，这个在前面提到过。压缩列表的定义和使用其实在源码的头部说明中是很清楚的。看一下英文的注释：The ziplist is a specially encoded dually linked list that is designed to be very memory efficient. It stores both strings and integer values, where integers are encoded as

一、skiplist 跳表跳表这个数据结构是新生的，在学习数据结构的时候儿是没有这个的。当然，也可以理解成是对数据结构的进一步的封装，这样理解的话，可能就会更准确一些。为什么叫跳表？想想生活中跳的动作，一般人走路是一步一步的走，而如果跳跃的话，一下子可以走好几步，但是付出的代价就是要多费些力气。其实跳表也是如此，正常的链表list，访问的时候儿是从头到尾（或者反过来）一条条的遍历，而跳表由于多了一些特殊的指针，可以一下子就访问距离自己更远的节点，并通过一些状态，来判定是否满足要求。如果满足就不再向前跳。

一、dict 字典在Redis中，字典就是HASH表。哈希表的优势在于查找速度快（理想状态下O（1）），但大小不好控制，大了浪费，小了冲突。而过多的冲突最终会使得哈希表退化。这就需要有一个处理机制，来达到容量和冲突解决的一个动态平衡。在Redis中，字典可以自动动态扩容，为了保证适应性和安全性，DICT不是一次完成扩容的，是渐进的，批次完成的。二、源码分析1、字典的定义：//字典的节点定义typedef struct dictEntry { void * key;//这个好理解，KEY

一、整体架构Redis作为一种KV型数据库，其主要的应用方式有几种：1、单机结构这种情况适用于小规模的应用，安全性也相对来说比较低。处理能力有限，其数据容量也不会太大。2、主从结构这种方式其实就是一主多备，既可以降低Master的读压力，又可以增强安全性。但是存在主从复制的安全性问题。仍然没有解决写压力。3、哨兵结构通过哨兵的监控，实现了主从结构的增强即主服务器...

redis源码分析之一——介绍一、Redis介绍在NoSql数据库中，要说当红“炸子鸡”，Redis是当仁不让的。而且它还有一个比较特别之处，它是用纯c语言实现的。这和其它一些相关的程序使用Java、Go等当红语言完成，Redis确实是比较另类的。不过，这也恰恰体现了其高性能的一个有力的保障的原因。Redis是基于内存型的数据库，虽然说其可以周期性的写入硬盘（这和Memcache有所不同），...

一、Flink的分布通信模型flink做为一个分布式的应用，它基于的通信当然是分布式的通信框架。在Flink中，可以分为两种通信方式，一种是通过网络的传输通信，一种是基于本地的数据交换通信。网络通信主要是用来连接节点间的通信（包括客户端和服务端），本地主要是线程内交换一些数据。本地主要是基于一系列的Oprator来实现的，这个在前面也已经看到过。这次主要分析这个。二、线程间通信在前面分析了...

flink分析使用之二入口代码分析一、简介在Flink中，启动的方式有三种，即local,standalone和Yarn,同时其还可以配置为高可用（HA）集群。它们的实现虽然有所异同，但是总体的原理是一致的。这里的源码分析从standalone的源码开始分析，即：org.apache.flink.runtime.entrypoint.StandaloneSessionClusterEntryp...

一、R语言的环境安装1、安装R语言sudo apt-get install r-base r-base-dev命令执行完成后， 输入命令R（大写），回车，启动交互shell，类似如下图：2、安装rstudio首先安装相关的库文件sudo apt-get install gdebi-core #这个其实用处不大，可以不安装sudo apt install gdebi libxml2...

一、简介在Flink中，其整体的运行机制如下图（图为网上下载，如果侵权立删）：从上图可以看出，在整个Flink启动后，会启动一个JobManager和多个TaskManger，这个很好理解，一般都是一个管理者对应着多个工作者。但是，其最核心的目的是处理来自外界的数据，在Flink中，对整体的数据接口进行了抽象：从上图可以看出，依据不同的层次Flink对数据的输入进行了抽象，从最顶层的S...

flink分析使用之四Job的启动一、介绍在老的flink版本中，工作是由Jobmanager（低版本）和JobMaster来管理的，Flink通过JobManager实现Client和TaskManager交互协作，Client将JobGraph提交给JobManager，利用JobGraph实现ExecutionGraph，然后分发到TaskManager上执行。从 flip-6起，开始通...

一、JobGraph在Flink中的有以下几种图，即StreamGraph，它用来生成JobGraph，然后再由分发器将其分发生成ExecutionGraph并进而形成Task任务执行的任务图（这个图就只是一个逻辑概念了）。JobGraph是非常重要的一环，其它的图以后再详细分析。学过图的都知道，图和其它数据结构明显不同的是，图有节点和边的概念。那么看一下Flink中这个图的定义：publ...

一、JobMaster和JobManager在上一篇着重分析了工作图的导入和分发，由于版本迭代的缘故，JobMaster和JobManager完成的工作逻辑基本是一样的，这里只介绍Jobmaster，这里不再介绍老的JobManager。在前面提到过，工作的图的传递和分发是通过JobManagerRunner的生成，递送到JobMaster，然后再由ExecutionGraph递送到Task。...

一、flink的任务在前面已经分析过了作业对任务的分发，那么，现在就可以分析任务的启动和执行了。任务可以通过RPC分发到指定位置。所以在此处需要对任务的分发有一个管理TaskManager，从宏观上看，Flink的每个TaskManager都是一个独立的JVM进程，为了更好的管理JVM进程，又要对TaskManager进行细化的管理，这时候儿就需要另外一个对象TaskSlot来负责对细节的管控。...

一、flink内存机制在前面的槽机制上，提到了内存的共享，这篇文章就分析一下，在Flink中对内存的管理。在Flink中，内存被抽象出来，形成了一套自己的管理机制。Flink本身基本是以Java语言完成的，理论上说，直接使用JVM的虚拟机的内存管理就应该更简单方便，但Flink为什么还要自己抽象出自己的内存管理呢？这首先要考虑Flink的应用场景，Flink是为大数据而产生的，而大数据使用会消...

一、介绍Flink是分布式大数据处理框架，那么网络通信就离不开了，从目前来看，几乎所有的开源的大型软件，尤其是Java的，基本已经不再倾向于自己写底层网络通信，毕竟有很多可以使用的Rpc网络通信框架可以来完善使用，Flink也是如此，它是基本Akka Rpc这款Rpc通信框架的。二、分析1、服务端先看一下测试代码的最基础的通信代码（RpcEndPointTest.java）：publi...

flink分析使用之一环境安装flink是近两年风头比较强劲的一个开源的流式计算框架，也有人将其定义为第四代大数据引擎，它的主要特点是支持内存流式的高吞吐、低延迟处理（这是不是现代大数据发展的特点）；支持带有事件的窗口操作；支持有状态计算的Exactly-once语义；支持轻量级分布式快照实现的容错；在JVM内部实现了内存管理；支持迭代计算；支持具有Backpressure功能的持续流模型；支...