Zookeeper学习之CAP和BASE理论

前言

随机分布式的发展，系统变得越来越复杂，于是如何构建一个兼顾可用性和一致性的分布式系统成为了无数个工程师探讨的难题，出现了诸如CAP和BASE这样的分布式系统经典理论。

ZooKeeper学习之分布式概念和特点

前言

随着计算机系统规模变得越来越大，将所有的业务单元集中部署在一个或若干个大型机上的体系结构，已经越来越不能满足当今计算机系统，尤其是大型互联网系统的快速发展，各种灵活多变的系统架构模型层出不穷。分布式的处理方式越来越受到业界青睐–计算机系统正在经历一场前所未有的从集中式向分布式架构的变革。

Spring Cloud fegin实现声明式接口调用

背景

前面我们介绍了Ribbon和Hystrix结合，实现对RestTemplate调用的负载均衡和服务降级。而Spring Cloud Fegin在此基础上做了进一步封装，由他来帮助我们定义和实现依赖服务接口的定义。在Spring Cloud Fegin的实现下，我们只需要通过创建接口并用注解来配置它既可完成对Web服务接口的绑定。它具备可插拔的注解支持，包括Feign注解、JAX-RS注解。它也支持可插拔的编码器和解码器。SpringCloud Feign还扩展了对Spring MVC注解的支持，同时还整合了Ribbon和Eureka来提供均衡负载的HTTP客户端实现。

Redis过期策略

前言

​ 我们都知道Redis是一个键值对内存数据库，我们设置键值对时，可以对键值对设置超时时间。所以那些过期了的键值对就需要一种清理策略来清理。需要清理的场景主要有两种，一种是Redis那些设置了超时时间并且已经超时的键值对，此时的键值对失效了需要被清理，这种场景会采用定时删除+惰性删除的策略来清理。另外一种是由于Redis配置的内存已经到达上限，需要对那些过期或者还没过期的键值对按照内存淘汰策略进行清理，释放部分内存。

Redis数据持久化

前言

​ Redis 的数据全部在内存里，之所以需要持久化在硬盘是为了在之后能重用数据，或者是为了防止系统故障、宕机导致内存中的数据全部丢失。另外，存储在Redis中的数据有可能是经过长时间计算得出的，或者有程序正在使用Redis存储的数据进行计算，所以用户会希望自己可以将这些数据存储起来以便之后使用，不需要重新计算了。

redis主从架构​

主从的优势

​ 单机的 redis，能够承载的 QPS 大概就在上万到几万不等。对于缓存来说，一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构，一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。

Redis 5种基本数据类型

前言

​ redis平时还是经常使用的，但是只是停留在基本使用上面，5种基本的数据类型基本也只是用了字符串，觉得还是有必要深入学习下Redis，从5种基本数据类型开始。

markdown插入本地图片小技巧

背景

​ markdown作为一种普通文本编辑器编写的标记语言，通过简单的标记语法，它可以使普通文本内容具有一定的格式，非常的好用，但是插入本地图片很不方便，接下来我们介绍一种非常实用的上传本地图片的方法。

Spring Cloud Hystrix实现服务短路和服务降级

背景

​ 在微服务架构中，我们将系统拆分成了一个个的服务单元，各单元应用间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会出现因等待出现故障的依赖方响应而形成任务积压，线程资源无法释放，最终导致自身服务的瘫痪，进一步甚至出现故障的蔓延最终导致整个系统的瘫痪。如果这样的架构存在如此严重的隐患，那么相较传统架构就更加的不稳定。为了解决这样的问题，因此产生了断路器等一系列的服务保护机制。

前言

​ 2018年终总结就提到要搭建一个个人博客，没想到这么快就完成了，其实使用Hexo+Github搭建博客还是挺方便的，这里记录下搭建过程。