分布式架构

声明：因为运行环境是基于linux系统的，在做此框架之前需要做一些前期的环境准备工作 CentOs下安装jdk7网上很多实例，因为博客后期作为框架的原生教程，故这边做详细的安装记录 首先在CentOs下下载jdk7解压文件,tar包安装(目前Oracle官方上，对于文件的下载，加了Cookie验证机制，所以直接下载文件包，会出现找不到的错误，最老土的办法，本地下载，使用FTP上传服务器)，我这边已经下载好了，通过ssh已经上传到指定的目录，这里直接讲解安装的过程。 一、准备工作 卸载OpenJDK 1.查找需要卸载的OpenJDK [root @cloud /] rpm -qa | grep openjdk | grep -v grep java-1.7.0-openjdk-1.7.0.75-2.5.4.2.el7_0.x86_64 java-1.6.0-openjdk-devel-1.6.0.34-1.13.6.1.el7_0.x86_64 java-1.7.0-openjdk-headless-1.7.0.75-2.5.4.2.el7_0.x86_64 java-1.6.0-openjdk-1.6.0.34-1.13.6.1.el7_0.x86_64 java-1.7.0-openjdk-devel-1.7.0.75-2.5.4.2.el7_0.x86_64 2.依次卸载

1、什么是FastDFS FastDFS 是用 c 语言编写的一款开源的分布式文件系统。 FastDFS 为互联网量身定制，充分考虑了 冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能 等指标，使用 FastDFS 很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。 FastDFS 架构包括 Tracker server 和 Storage server 。客户端请求 Tracker server 进行文件上传、下载，通过 Tracker server 调度最终由 Storage server 完成文件上传和下载。 Tracker server 作用是负载均衡和调度 ，通过 Tracker server 在文件上传时可以根据一些策略找到 Storage server 提供文件上传服务。可以将 tracker 称为追踪服务器或调度服务器。 Storage server 作用是文件存储 ，客户端上传的文件最终存储在 Storage 服务器上， Storageserver 没有实现自己的文件系统而是利用操作系统 的文件系统来管理文件。可以将 storage 称为存储服务器。 图解： 本文省略了FastDFS在linux系统中的安装 2、上传流程 3、下载流程 4、上传小demo a、导入依赖 <!-- 文件上传组件 --> <dependency> <groupId

BaikalDB是一个分布式可扩展的存储系统，支持PB级结构化数据的随机实时读写。 提供MySQL接口，支持常用的SELECT，UPDATE，INSERT，DELETE语法。提供各种WHERE过滤、GROUP BY聚合，HAVING过滤，ORDER BY排序等功能，用户可以组合实现各种在线OLAP需求，具备秒级别的亿级数据扫描聚合能力。另外，为了满足各种业务的检索需求，该系统内置全文检索需求，满足大部分快速检索的业务场景。 在虚拟化部署方面，该系统采用share-nothing的架构，可部署在容器中，也实现了多租户隔离，有自定义用户的身份识别和权限访问控制等功能。 BaikalDB 的主要特性如下： 全自主化的容量管理，可以自动扩容和自动数据均衡，支持自动故障迁移，无单点，很容易实现云化，目前运行在Paas虚拟化平台之上。 面向查询优化，支持各种二级索引，包括全文索引，支持常用的 OLAP 需求，支持层级模型。 兼容 mysql 协议，对应用方提供 SQL 界面，支持高性能的Schema 加列。 基于 RocksDB 实现单机存储，基于Multi Raft 协议（我们使用braft库）保障副本数据一致性，基于brpc实现节点通讯交互。 支持多租户，meta 信息共享，数据存储完全隔离。 其中 BaikalStore 负责数据存储，用 region 组织，三个 Store 的

TBase 是腾讯数据平台团队在开源的 PostgreSQL 基础上研发的企业级分布式 HTAP 数据库管理系统： 具备高性能可扩展的分布式事务能力，支持 RC 和 RR 两种隔离级别； 通过安全、管理、审计三权分立体系，提供全方位的数据安全保证机制； 支持高性能分区表，可使得数据检索效率成倍提升； SQL 方面兼容 2003 标准、PostgreSQL 语法和常用 Oracle 函数&数据类型、窗口函数等； 提供大小商户数据分离、冷热数据分离等高效的数据治理能力 TBase 架构： 集群中有三种节点类型，各自承担不同的功能，通过网络连接成为一个系统。这三种节点类型分别是： Coordinator：协调节点，对外提供接口，负责数据的分发和查询规划，多个节点位置对等，每个节点都提供相同的数据库视图，CN 存储系统的全局元数据。 Datanode：处理存储本节点相关的元数据，每个节点还存储数据的一个分片。在功能上，DN 节点负责完成执行协调节点分发的执行请求。 GTM: 全局事务管理器(Global transaction manager.)，负责管理集群事务信息，同时管理集群的全局对象，比如序列，除此之外 GTM 上不提供其他的功能。 TBase 功能介绍： 分布式事务全局一致性能力：通过拥有自主专利的分布式事务一致性技术，包括两阶段提交(Two Phase Commit

随着各个业务系统的不断增加，以及各业务系统数据量不断激增，业务用户的分析诉求越来越多且变化很快，IT数据支撑方的工作变得越来越复杂。 1、数据来自多个不同的系统，存在需要跨数据源分析，需要对接各种不同数据源等问题。 2、需要分析的数据体量越来越大，并且要快速获得分析结果的问题。 3、部分数据还需要二次加工处理的问题。 供数支撑方在业务系统的前端看起来基本没有任何操作，但背后的逻辑十分复杂，实现难度也很大。就像看得到的是冰山一角，看不到的是海水下绝大部分的支撑。 为了解决日益激增的大数据量分析诉求，大部分公司会通过搭建Hadoop、Spark等大数据架构，配以BI工具做数据层面的分析，来搭建这样一整套大数据分析平台。 大数据分析很关键的一个点在于性能：取数快不快，分析响应快不快，能否实时？ 这个问题除了平台的底层架构，BI（ 商业智能 ）的运行性能也有很大相关。 大家可能普遍认为的BI，就是一个数据展现工具，在前端看起来没有太多有技术含量的操作，但背后的逻辑十分复杂，实现难度也很大。就像看得到的是冰山一角，看不到的是海水下绝大部分的支撑。 好的BI工具都有与之依赖的数据引擎，数据引擎的作用一方面是数据响应的性能（数据量、速率），还有很重要的一点是能否适应企业不同业务情况的模式/方案。比如小数据快速读取，大数据分布式并行运算，节点数据实时展现等等..... FineBI V5

课程主讲： 互联网应用高级架构师 白贺翔 涉及技术： Redis 、 SSDB 、 Memcached 课程描述： 介绍互联网 分布式 技术的重要性、背景、应用范围；目前互联网行业使用分布 式缓存进行设计的比例，以及大型网站使用的方式和方法，讲解分布式 缓存技 术 、数据类型、实战应用场景、缓存库主从同步、读写分离、高并发、安全性、 事务特性、分布式锁、负载均衡、 Session 共享、发布订阅、数据持久化、哨兵、 高可用、可扩展性、水平垂直扩容、集群环境搭建与应用等。 课程目录 01_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第一节 02_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第二节 03_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第三节 04_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第四节 05_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第五节 06_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第六节 07_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第七节 08_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第八节 09_白贺翔_互联网应用架构师公开课《大型网站分布式缓存技术》第九节 教程下载地址： 互联网分布式缓存技术 本文来自 >> 尚学堂 ； 转载请注明

一，复制，对数据进行备份，实现搞可用，提高吞吐量，实现高性能。 　　1，主从架构 　　2，多主架构 　　3，主主从从 　　4，主备 （实际用得多） 二，分片/分库分表 （） 1，垂直拆分 　　1，垂直分表 　　2，垂直分库 　　 如果做垂直分库，应该把有关联的表放在同一个库中，因为数据库的事务不能跨库，不能使用inner join, order_by ,等链接查询，只能分次数查询，在应用端在合并。 2，水平拆分 　　1，水平分表 　　2，水平分库分表 　　3，分布式id 　需求：水平分表后，需要保证多表id冲突问题 　雪花算法：1bit + 时间戳41 + 机器id10 序列号12 　id 取模运算 分布式事务 ： 在一个事务不能完成的情况下， 核心：二阶段提交协议（简称2PC协议/XA协议） 问题：会出现事务等待情况，增加死锁的机率 基于状态/消息的最终一致性方案（使用较多） 悲观锁： 　　开发者主动设置 乐观锁： 　　先不加锁（假设没有并发），但更新前校验数据的一致性，手动代码实现（先查在更新） 　　 来源： https://www.cnblogs.com/wjun0/p/11881212.html

Eureka、Consul、Zookeeper的基本原理与比较。 前言 在云计算和容器化技术发展火热的当下，对于微服务架构，服务注册与发现组件是必不可少的。在传统的服务架构中，服务的规模处于运维人员的可控范围内。当部署服务的多个节点时，一般使用静态配置的方式实现服务信息的设定。在微服务应用中，服务实例的数量和网络地址都是动态变化的，这对系统运维提出了巨大的挑战。因此，动态的服务注册与发现就显得尤为重要。 解决的问题 在一个分布式系统中，服务注册与发现组件主要解决两个问题：服务注册和服务发现。 服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。 服务发现：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。 除此之外，服务注册与发现需要关注监控服务实例运行状态、负载均衡等问题。 监控：微服务应用中，服务处于动态变化的情况，需要一定机制处理无效的服务实例。一般来讲，服务实例与注册中心在注册后通过心跳的方式维系联系，一旦心跳缺少，对应的服务实例会被注册中心剔除。 负载均衡：同一服务可能同时存在多个实例，需要正确处理对该服务的负载均衡。 CAP CAP原则，指的是在一个分布式系统中，Consistency(一致性)

https://www.cnblogs.com/wupeixuan/p/9302496.html 第一章主要讲的是分布式架构，主要包含以下内容： 集中式的特点 分布式的特点 分布式环境的各种问题 ACID 分布式事务 CAP和BASE理论 1 | 1 集中式与分布式的特点 集中式的特点：部署结构简单（因为基于底层性能卓越的大型主机，不需考虑对服务多个节点的部署，也就不用考虑多个节点之间分布式协调问题） 分布式的特点： 分布性 对等性 并发性 缺乏全局时钟 故障总是会发生 1 | 2 分布式环境的各种问题 分布式环境的各种问题： 通信异常：主要是因为网络本身的不可靠性 网络分区：当网络发生异常时，导致部分节点之间的网络延时不断增大，最终导致部分节点可以通信，而另一部分节点不能。 三态（成功、失败与超时） 节点故障：组成分布式系统的服务器节点出现宕机或“僵死”现象 1 | 3 ACID与分布式事务 事务是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元，狭义上的事务特指数据库事务。 事务有四个特性，分别是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），简称为事务的ACID特性。 原子性（Atomicity）：必须是一个原子的操作序列单元，只允许出现两种状态之一（全部成功执行，全部不执行）。

1、Zookeeper 的由来 在Hadoop生态系统中，许多项目的Logo都采用了动物，比如 Hadoop 和 Hive 采用了大象的形象，HBase 采用了海豚的形象，而从字面上来看 ZooKeeper 表示动物园管理员，所以大家可以理解为 ZooKeeper就是对这些动物（项目组件）进行一些管理工作的。 对于单机环境多线程的竞态资源协调方法，我们一般通过线程锁来协调对共享数据的访问以保证状态的一致性。 但是分布式环境如何进行协调呢？于是，Google创造了Chubby，而ZooKeeper则是对于Chubby的一个开源实现。 ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。由于ZooKeeper的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护、组服务、分布式消息队列、分布式通知/协调等。它被设计为易于编程，使用文件系统目录树作为数据模型。 2、ZooKeeper集群模式典型架构 2.1 角色 Zookeeper服务自身组成一个集群(2n+1个服务允许n>=1个失效)。Zookeeper集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种 Leader 一个Zookeeper集群同一时间只会有一个实际工作的Leader