高可用

“微服务架构”的话题非常之火，很多朋友都在小窗我，说怎么做服务化？解答“怎么做”之前，先得了解“为什么做”。 画外音：做技术千万不能是这种思路，“别人都在做，所以我们也要搞”。 并不是所有的业务都适合“服务化”，互联网高可用架构，到底为什么要服务化？ 服务化之前，高可用架构是什么样的？ 在服务化之前，互联网的典型高可用架构如下： （1） 客户端 ，APP，H5，小程序，PC浏览器； （2） 后端入口 ，高可用的反向代理nginx集群； （3） 站点应用 ，高可用的web-server集群； （4） 后端存储 ，高可用db集群； 更典型的，web-server集群通过DAO/ORM等技术来访问数据库。 可以看到，最初是没有服务层的， 此时架构会碰到什么典型痛点呢？ 架构痛点一：代码到处拷贝 举一个最常见的业务例子，用户数据访问，绝大部分公司都有一个数据库存储用户数据，各个业务都有访问用户数据的需求。 在有用户服务之前，各个业务线都是自己通过DAO写SQL访问user库来存取用户数据，这无形中就导致了代码的拷贝。 架构痛点二：复杂性扩散 随着并发量的越来越高，用户数据的访问数据库成了瓶颈，需要加入缓存来降低数据库的读压力，于是架构中引入了缓存，如果没有统一的服务层，各个业务线都需要关注缓存的引入导致的复杂性。 对于写请求，所有业务线都要升级代码： （1）先淘汰cache； （2

概述 2018 年 10 月 31 日的凌晨，这个伟大的日子里，Spring Cloud Alibaba 正式入驻了 Spring Cloud 官方孵化器，并在 Maven 中央库发布了第一个版本。 Spring Cloud for Alibaba 0.2.0 released The Spring Cloud Alibaba project, consisting of Alibaba’s open-source components and several Alibaba Cloud products, aims to implement and expose well known Spring Framework patterns and abstractions to bring the benefits of Spring Boot and Spring Cloud to Java developers using Alibaba products. Spring Cloud for Alibaba，它是由一些阿里巴巴的开源组件和云产品组成的。这个项目的目的是为了让大家所熟知的 Spring 框架，其优秀的设计模式和抽象理念，以给使用阿里巴巴产品的 Java 开发者带来使用 Spring Boot 和 Spring Cloud 的更多便利。 Spring Cloud

最近在自己的笔记本电脑上搭建了Apache Hadoop分布式集群，采用了最新的稳定版本2.8，并配置了NameNode、ResourceManager的HA高可用，方便日常对Hadoop的研究与测试工作。详细的搭建过程如下： 1、安装docker，创建docker容器，用于搭建hadoop节点 docker真是个好东西啊，当要在自己的笔记本上搭建分布式集群时，由于CPU、内存、磁盘有限，无法在VMware上虚拟出太多节点，这时使用docker创建几个容器，就能轻松搭建一个分布式集群了。 （1）先在VMware上安装centos6.9，作为宿主机，然后安装docker，具体过程见我另一篇博文： Centos6.9安装docker （2）然后再docker hub中拉取centos镜像，用于创建分布式集群的节点，推荐在docker中安装centos6（ docker中的centos7有坑， 被坑过 ，呜呜 ），具体过程见我另一篇博文： docker中安装centos6 （3）centos镜像准备好后，就开始创建docker容器，用于搭建hadoop的节点 # 创建4个节点，用于搭建hadoop docker run -it --name hadoopcentos1 centos:6 /bin/bash docker run -it --name hadoopcentos2

7. Redis持久化有哪几种方式？不同的持久化机制都有什么优缺点？持久化机制具体底层是如何实现的？ 为什么要持久化？ 如果只是存在内存里，如果redis宕机再重启，内存数据就丢失了，所以要用持久化机制。 将数据写入内存的同时，异步的慢慢将数据写入磁盘文件，定期同步或备份到云存储服务上，进行持久化。 如果redis宕机重启，自动从磁盘加载之前持久化的一些数据，也许会丢失少量数据，但至少不会丢所有数据。 Redis 持久化的两种方式: RDB 和 AOF RDB(Redis Database) : 是对redis中的数据执行 周期性 的持久化。 简单说就是每个几分钟或几个小时，生成redis内存中数据的一份全量快照副本。 AOF(Append-Only-File) ：是对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集。 现在操作系统中，写文件不是直接写磁盘，会先写os cache(linux)，然后到一定时间从os cache写到磁盘文件。 如果同时使用 RDB 和 AOF 两种持久化机制，那么在 redis 重启的时候，会使用 AOF 来重新构建数据，因为 AOF 中的数据更加完整。 RDB 优缺点： 优点： 1. 非常适合做冷备份。 RDB生成多个文件

FROM： https://www.cnblogs.com/jajian/p/10014145.html 之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务。 首先说一下，这里可能会牵扯到一些 Spring Cloud 的原理，如果有不太清楚的同学，可以参考之前的文章： 《拜托，面试请不要再问我Spring Cloud底层原理！》 。 1 | 0 业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 2 | 0 进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子

keepalived 保持在线状态，也就是所谓的高可用或热备，它集群管理中 保证集群高可用的一个服务软件 ，其功能类似于heartbeat，用来防止 单点故障 (单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生。VRRP协议这个协议就是keepalived实现的基础 VRRP https://www.cnblogs.com/betterquan/p/11903616.html 简单了解就是 1）VRRP是用来实现路由器冗余的协议。 2）VRRP协议是为了消除在静态缺省路由环境下路由器单点故障引起的网络失效而设计的主备模式的协议，使得发生故障而进行设计设备功能切换时可以不影响内外数据通信，　　不需要再修改内部网络的网络参数。 3）VRRP协议需要具有IP备份，优先路由选择，减少不必要的路由器通信等功能。 4）VRRP协议将两台或多台路由器设备虚拟成一个设备，对外提供虚拟路由器IP（一个或多个）。然而，在路由器组内部，如果实际拥有这个对外IP的路由器如果工作正常的话，　　·就是master，或者是通过算法选举产生的，MASTER实现针对虚拟路由器IP的各种网络功能，如ARP请求，ICMP，以及数据的转发等，其他设备不具有该IP，状态是BACKUP。　　除了接收MASTER的VRRP状态通告信息外，不执行对外的网络功能，当主级失效时

kafka 如何保证数据不丢失 https://www.cnblogs.com/MrRightZhao/p/11498952.html 一般我们在用到这种消息中件的时候，肯定会考虑要怎样才能保证数据不丢失，在面试中也会问到相关的问题。但凡遇到这种问题，是指3个方面的数据不丢失，即：producer consumer 端数据不丢失 broker端数据不丢失下面我们分别从这三个方面来学习，kafka是如何保证数据不丢失的 一.producer 生产端是如何保证数据不丢失的 　　1.ack的配置策略 　　acks = 0　　　　生产者发送消息之后 不需要等待服务端的任何响应，它不管消息有没有发送成功，如果发送过程中遇到了异常，导致broker端没有收到消息，消息也就丢失了。实际上它只是把消息发送到了socketBuffer(缓存)中，而socketBuffer什么时候被提交到broker端并不关心，它不担保broker端是否收到了消息，但是这样的配置对retry是不起作用的，因为producer端都不知道是否发生了错误，而且对于offset的获取永远都是-1，因为broker端可能还没有开始写数据。这样不保险的操作为什么还有这样的配置？kafka对于收集海量数据，如果在收集某一项日志时是允许数据量有一定丢失的话，是可以用这种配置来收集日志。　　　　acks = 1(默认值)　　　

在 Spring Cloud 体系中，几乎每个角色都会有两个以上的产品提供选择，比如在注册中心有：Eureka、Consul、zookeeper、etcd 等；网关的产品有 Zuul、Spring Cloud Gateway 等。在注册中心产品中，最常使用的是 Eureka 和 Consul，两者各有特点，企业可以根据自述项目情况来选择。 前面给大家详细介绍了 Eureka ，本节给大家介绍 Consul 的使用。 什么是Consul Consul 是 HashiCorp 公司推出的开源产品，用于实现分布式系统的服务发现、服务隔离、服务配置，这些功能中的每一个都可以根据需要单独使用，也可以同时使用所有功能。Consul 官网目前主要推 Consul 在服务网格中的使用。 与其它分布式服务注册与发现的方案相比，Consul 的方案更“一站式”——内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其它工具。Consul 本身使用 go 语言开发，具有跨平台、运行高效等特点，也非常方便和 Docker 配合使用。 Consul 的主要特点有： Service Discovery : 服务注册与发现，Consul 的客户端可以做为一个服务注册到 Consul，也可以通过 Consul 来查找特定的服务提供者

前言 秒杀大家都不陌生。自2011年首次出现以来，无论是双十一购物还是 12306 抢票，秒杀场景已随处可见。简单来说，秒杀就是在同一时刻大量请求争抢购买同一商品并完成交易的过程。从架构视角来看，秒杀系统本质是一个高性能、高一致、高可用的三高系统。而打造并维护一个超大流量的秒杀系统需要进行哪些关注，就是本文讨论的话题。 整体思考 首先从高维度出发，整体思考问题。秒杀无外乎解决两个核心问题，一是并发读，一是并发写，对应到架构设计，就是高可用、一致性和高性能的要求。关于秒杀系统的设计思考，本文即基于此 3 层依次推进，简述如下—— 高性能。 秒杀涉及高读和高写的支持，如何支撑高并发，如何抵抗高IOPS？核心优化理念其实是类似的：高读就尽量"少读"或"读少"，高写就数据拆分。本文将从动静分离、热点优化以及服务端性能优化 3 个方面展开 一致性。 秒杀的核心关注是商品库存，有限的商品在同一时间被多个请求同时扣减，而且要保证准确性，显而易见是一个难题。如何做到既不多又不少？本文将从业界通用的几种减库存方案切入，讨论一致性设计的核心逻辑 高可用。 大型分布式系统在实际运行过程中面对的工况是非常复杂的，业务流量的突增、依赖服务的不稳定、应用自身的瓶颈、物理资源的损坏等方方面面都会对系统的运行带来大大小小的的冲击。如何保障应用在复杂工况环境下还能高效稳定运行，如何预防和面对突发问题

前言 秒杀大家都不陌生。自2011年首次出现以来，无论是双十一购物还是 12306 抢票，秒杀场景已随处可见。简单来说，秒杀就是在同一时刻大量请求争抢购买同一商品并完成交易的过程。从架构视角来看，秒杀系统本质是一个高性能、高一致、高可用的三高系统。而打造并维护一个超大流量的秒杀系统需要进行哪些关注，就是本文讨论的话题。 整体思考 首先从高维度出发，整体思考问题。秒杀无外乎解决两个核心问题，一是并发读，一是并发写，对应到架构设计，就是高可用、一致性和高性能的要求。关于秒杀系统的设计思考，本文即基于此 3 层依次推进，简述如下—— 高性能。 秒杀涉及高读和高写的支持，如何支撑高并发，如何抵抗高IOPS？核心优化理念其实是类似的：高读就尽量"少读"或"读少"，高写就数据拆分。本文将从动静分离、热点优化以及服务端性能优化 3 个方面展开 一致性。 秒杀的核心关注是商品库存，有限的商品在同一时间被多个请求同时扣减，而且要保证准确性，显而易见是一个难题。如何做到既不多又不少？本文将从业界通用的几种减库存方案切入，讨论一致性设计的核心逻辑 高可用。 大型分布式系统在实际运行过程中面对的工况是非常复杂的，业务流量的突增、依赖服务的不稳定、应用自身的瓶颈、物理资源的损坏等方方面面都会对系统的运行带来大大小小的的冲击。如何保障应用在复杂工况环境下还能高效稳定运行，如何预防和面对突发问题