分布式技术

spring cloud本身提供的组件就很多，但我们需要按照企业的业务模式来定制企业所需要的通用架构，那我们现在需要考虑使用哪些技术呢？ 下面我针对于spring cloud微服务分布式云架构做了以下技术总结，希望可以帮助到大家： View： H5、Vue.js、Spring Tag、React、angularJs Spring Boot/Spring Cloud： Zuul、Ribbon、Feign、Turbine、Hystrix、Oauthor2、Sleuth、API Gateway、Spring Cloud、Config Eureka、SSO、Spring Cloud、 BUS、Turbine、Zipkin、Cache、Spring Cloud Admin、API Gateway、ELK Spring Cloud Security、 Spring Cloud Stream Component： RoketMQ、Kafka、MongoDB、OSS、Redis、Swagger、Zuul、Label、BASE、Charts、Utils DAO： Spring Data、Mybatis、OSS、 DTO Data Storage： RDBS DFS、NOSQL/Hadoop Infrastructure： LogBack、BUS、Jenkins、Zipkin、Druid

《微服务分布式构架开发实战》 《Elasticsearch大数据搜索引擎》 《ZooKeeper：分布式过程协同技术详解》 《Kafka权威指南》 《图解数据结构-使用Java》 《大数据架构商业之路从业务需求到技术方案 《循序渐进学Docker》 -----------------------------关注公众号免费获取海量学习视频及电子书--------------------------- 文章来源: Spring Cloud,分布式，高并发，kafka，数据结构。海量电子书免费获取。

近年来，美国在 FinTech 领域不断实现技术突破和创新，特别是区块链方向，传统 IT 巨头、金融企业纷纷涉足其中，先后创建了 Hyperledger、R3、EEA 等著名区块链技术与应用联盟，积极地开展开源项目孵化，并在多个应用领域。 为了更好地发展区块链技术，防范技术高速发展所孕育的潜在风险，行业标准刻不容缓。在此背景下，工信部中国电子技术标准化研究院牵头组织中国区块链技术和产业发展论坛主要成员，开展了《信息技术区块链和分布式账本技术参考架构》标准的研制工作。 1. 参考架构的定位 （1）使用通俗的语言来描述区块链和分布式账本技术 （2）区块链或分布式账本技术的理想原型结构 （3）描述适用于区块链技术的标准范围 2. 参考架构的视角 可以从业务、法律或技术视角来看待区块链技术 a）从业务角度来看，区块链是一个在相互认同的参与者之间，促进价值、资产或其他实体转移的交换网络 b）从法律角度来看，区块链账本上的交易是经过验证、不可否认且无法篡改的，它不需要中介或第三方参与。 c）从技术角度来看，区块链是一个引用其他数据存储作为账本数据、全局复制的分布式账本。 3. 参考架构的设计理念 首先，从分布式应用架构师和开发人员角度来设计一种区块链平台参考架构，如下图： 它包含了 6 个层次：1）基础设施 2）安全 3）数据 4）账本 5）开发 6）分布式应用 ，我们一一对照解读一下。 （1

　　 分布式记账 问题由来已久。自以电子计算机为主要记账手段的数字化账本诞生以来，商业活动参与者首先要寻找一个多方均能信任的第三方来记账，确保交易记录的准确。然而，随着商业活动的规模越来越大，商业过程愈加动态和复杂，很多场景下难以找到符合要求的第三方记账方（例如供应链领域动辄涉及来自多个行业的数百家参与企业）。这就需要交易各方探讨在多方分布式场景下进行协同记账的可能性。 　　技术的革新正在对我们现有的生活方式产生深远的影响，尤其突出的一点就是日益紧密的社会联系。而这种联系来自于互联网赋予的信息实时分享能力。 　　如今，又一股划时代的科技影响力随着互联网价值应运而生。如信息传输般安全实时地追踪和传输价值(如资金或资产)，很可能改变我们的生活和交易方式。 　　这股影响力的核心技术，即分布式记账或区块链，它不仅能影响单个企业，亦能改变整个行业及其供应链。同时，将助力现有商业模式及实现方式的转型。因此，作为专业会计师，应当理解技术发展核心及其对自身角色的重要影响。 　　实际上，可以很容易设计出一个简单粗暴的分布式记账结构，（一）。多方均允许对账本进行任意读写，一旦发生新的交易即追加到账本上。这种情况下，如果参与多方均诚实可靠，则该方案可以正常工作；但是一旦有参与方恶意篡改已发生过的记录，则无法确保账本记录的正确性。 　　为了防止有参与者对交易记录进行篡改，需要引入一定的验证机制。很自然地

课程简介： 升级版的内容特色： 面向人群： 学习收益： 课程大纲： 第一课 静态网页爬虫：爬虫的基础技术 HTML CSS 选择器 JavaScript 介绍 lxml 及 XPath Python 里的网络请求 高速位缓存设计：BloomFilter 第一个爬虫：蚂蜂窝的游记 第二课 登录及动态网页的抓取 表单 网站登录及Cookie Headless 的浏览器：PhantomJS 浏览器的驱动：Selenium 动态网页数据获取 第三课 微博的抓取 微博网站分布及结构分析 通过动态页面来抓取 微博网络接口的逆向分析 Java 的反编译 加密库 源代码的接口分析 第四课 多线程与过进程的爬虫 第五课 微博数据的存储：分布式数据库及应用 SQL 与 NoSQL Hadoop 架构 HDFS HBase MongoDB Redis 基于分布式数据库的分布式爬虫 第六课 多机并行的微博抓取：分布式系统设计 Socket 编程 Master 设计 Slave 设计 任务调度及通信协议 分布式集群部署的爬虫 第七课 分布式系统进阶：复杂的分布式机制 分布式应用协调服务：ZooKeeper 分布式消息队列管理：RabbitMQ/Kafka 服务发布及注册 灰度升级 第八课 微博数据查询：分布式数据库系统的优化及负载均衡 复制与分片 流量控制及均衡 分布式事物及锁 Redis 的核心技术介绍

最新后端架构师技术图谱 深呼吸，慢慢学 ，技术长路漫漫… 数据结构 二叉树 完全二叉树 平衡二叉树 二叉查找树（BST） 红黑树 B-，B+，B*树 LSM 树 队列 集合 链表、数组 字典、关联数组 树 BitSet 常用算法 KPM 算法 选择排序 冒泡排序 插入排序 快速排序 归并排序 希尔排序 堆排序 计数排序 桶排序 基数排序 二分查找 Java 中的排序工具 排序、查找算法 布隆过滤器 字符串比较 深度优先、广度优先 贪心算法 回溯算法 剪枝算法 动态规划 朴素贝叶斯 推荐算法 最小生成树算法 最短路径算法 并发 Java中的锁和同步类 公平锁 & 非公平锁 悲观锁 & 乐观锁 & CAS ABA 问题 CopyOnWrite容器 RingBuffer 可重入锁 & 不可重入锁 互斥锁 & 共享锁 死锁 事务 ACID 特性 事务的隔离级别 多线程 线程安全 一致性、事务 锁 操作系统 计算机原理 进程 线程 协程 Linux 设计模式 康威定律 设计模式的六大原则 23种常见设计模式 应用场景 单例模式 责任链模式 MVC IOC AOP UML 微服务思想 运维 & 统计 & 技术支持 OpenStack Docker KVM Xen OpenVZ TDD 理论 单元测试 压力测试 全链路压测 A/B Test Ansible puppet chef Jenkins

集群 小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群。 分布式 为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群。 节点 节点是指一个可以独立按照分布式协议完成一组逻辑的程序个体。在具体的项目中，一个节点表示的是一个操作系统上的进程。 副本机制 副本(replica/copy)指在分布式系统中为数据或服务提供的冗余。 数据副本指在不同的节点上持久化同一份数据，当出现某一个节点的数据丢失时，可以从副本上读取到数据。（张三请假了，李四负责顶替张三的工作）数据副本是分布式系统中解决数据丢失问题的唯一手段。 服务副本表示多个节点提供相同的服务，通过主从关系来实现服务的高可用方案。 中间件 中间件位于操作系统提供的服务之外，又不属于应用，他是位于应用和系统层之间为开发者方便的处理通信、输入输出的一类软件，能够让用户关心自己应用的部分。 一个成熟的大型网站系统架构并不是一开始就设计的非常完美，也不是一开始就具备高性能、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步完善演变过来的。在这个过程中，开发模式、技术架构等都会发生非常大的变化。 阶段一，单应用架构

分布式缓存 分布式缓存 知识点 jvm内置缓存ehcache ehcache 的五种集群模式 ehcache + Redis 实现一级缓存、二级缓存 分布式Redis缓存持久化 分布式Redis缓存水平拆分 分布式Redis缓存主从复制 分布式Redis缓存集群模式 分布式Redis缓存穿透、雪崩、效应 基于Redis实现分布式锁 为什么使用缓存、缓存用在什么地方？ 使用缓存技术为了减轻服务器压力 单个 jvm 缓存简单实现 // 单个jvm 缓存简单实现 @Component public class MapCache < K , V > { // 缓存容器使用 ConcurrentHashMap不需要考虑线程安全问题 public final Map < K , V > concruent = new ConcurrentHashMap <>(); public V get ( K k ){ return concruent . get ( k ); } public void put ( K k , V v ){ concruent . put ( k , v ); } public void remove ( K k ){ concruent . remove ( k ); } } springboot 开启 ehcache 缓存 开启缓存 @EnableCaching

随承载用户数量的增加和容灾的需要，越来越多互联网后台系统从单机模式切换到分布式集群。回顾自己毕业五年来的工作内容，同样有这样的转变。 毕业头两年负责维护运行在刀片机上的业务，在机房里拔插单板的日子是我逝去的青春。设备之间通过VCS组成冷备，但即使有双机软件保护，宕机、网络丢包等问题发生时业务仍会受影响。这样的系统架构下为保证SLA，有时候需要深入Linux系统内核或硬件层面分析机器重启的原因。 接下来负责维护承载在分布式集群上的业务，相比前面的工作，这个阶段主要关注点不是单节点的异常，更多是系统整体的稳定和健壮。面对纷繁复杂的系统，刚开始的时候有这样的感觉： 庞大复杂的分布式系统前，应该从哪方面入手提升对其的认识和理解、提升专业性？网上可以找到很多分布式系统相关的论文和资料，但归纳起来要表达的主要意思是什么？ 结合自己这几年的工作经验，总结分布式系统的核心就是解决一个问题：不同节点间如何达成共识。 看似简单的问题因网络丢包、节点宕机恢复等场景变得复杂，由此才衍生出很多概念、协议和理论。为探究共识问题最大能解决的程度，于是有FLP、CAP边界理论；为在特定条件和范围内解决该问题，于是有一致性协议Paxos、Raft、Zab和Viewstamped Replication；为构建这些协议，于是有多数派、Leader选举、租约、逻辑时钟等概念和方法。

分布式系统一致性问题解决实战 一、背景及问题描述 业务背景： 商户提交表单数据至旺铺（deco项目，以下皆称为deco），deco需要接入poi系统进行装修内容的人工审核，详细流程见下图。 问题： 店铺装修审核状态在deco系统和poi系统之间不一致，下图中1，2，3步提交流程会出现同一次提交审核流在deco系统中的装修状态为未装修，而在poi系统为审核中。同样在4，5，6步骤的审核回调过程也会有同类的状态不一致问题。两块问题都是同一技术问题，本文只以1，2，3步提交过程为例进行分析解决。 二、问题分析 1. 关系型数据事务在分布式系统中的问题 从业务中抽离出来，问题的核心原因可用下图流程模型来描述。 系统A的某个业务功能包含两步操作，第一步把数据写入A系统本地库，第二步远程调用系统B，这两步操作在A系统用一个数据库事务来包装。伪代码如下： $db->begain(); // 第一步操作本地数据库 $res = $db->update($sql_a); if (!$res) { $db->rollback(); return; } // 第二步远程调用B系统 $res = $http_request->get($url_b); if ('success' != $res) { $db->rollback(); return; } $db->commit(); 第一步有两种结果成功