分布式技术

根据阿里云《分布式文件存储系统技术及实现》整理而成。 1 分布式存储的客观需求 存储容量大 考虑对1PB数据进行排序，输入输出都需要1PB，算上中间临时数据，总共需要3-4PB。考虑多用户使用，则集群需要的总的存储空间大于100PB。 高吞吐量，如1PB数据排序需要在2小时内完成，每秒需要几十GB 数据可靠性，在数据规模增长时，降低数据丢失 服务高可用，99.95%意味着每年每年只有4-5小时不可用 高效运维，将日常硬件处理做成流程化，对监控报警要有完善支持 低成本，保证数据安全，正确服务稳定前提下，降低成本，才是分布式存储的核心竞争力 2 小概率事件对分布式系统挑战 单机系统下很少发生的事件，在大规模分布式系统中就会经常发生。 可能发生的小概率问题有： 1 磁盘错误 单机下运行稳定，集群下可能出现频繁。要考虑如何发现慢节点自动规避，发现机器宕机自动绕过。 2 Raid卡故障 发生在高可用节点上的事件。Raid卡是带有电池的缓存块，写入速度很快，能够在断电时保存数据。利用raid卡先缓存数据，之后再写入磁盘中。 3 网络故障 网络架构是一种树形结构，通过顶层交换机连接下层交换机，交换机下连接多台机器。 当上连交换机节点出错时，一部分主机将与其他主机分离，无法发挥作用。 可以将关键角色分布在不同的交换机下，将数据存储多份，某些机器失效时还可以访问到数据。 4 电源故障

一、亚马逊的架构规定 　　最早实践分布式服务化架构思想的公司应该是亚马逊，它早在 2002 年就颁布了下列架构规定，这应该就是 AWS（Amazon Web Service）出现的基础： 　　1. 所有团队的程序模块都要通过 Service Interface 方式将其数据与功能开放出来。 　　2. 团队间程序模块的信息通信，都要通过这些接口。 　　3. 除此之外没有其它的通信方式。其他形式一概不允许：不能直接链接别的程序（把其他团队的程序当做动态链接库来链接），不能直接读取其他团队的数据库，不能使用共享内存模式，不能使用别人模块的后门，等等。唯一允许的通信方式是调用 Service Interface。 　　4. 任何技术都可以使用。比如：HTTP、CORBA、Pub/Sub、自定义的网络协议等。 　　5. 所有的 Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。 　　6. 不这样做的人会被炒鱿鱼。 　　前面提到过，分布式系统架构会带来很多问题，譬如： 　　1. 一个线上故障的工单会在不同服务和不同团队中转过来转过去； 　　2. 每个团队都可能成为一个潜在的 DDoS 攻击者，除非每个服务都做好配额和限流； 　　3. 监控和查错变得更复杂

文章目录 一、Redis 集群结构以及设计理念 1. Redis 集群架构模式有哪几种？ 2. Redis 集群最大节点个数是多少？ 3. Redis 集群的主从复制模型是怎样的？ 4. 请介绍一下 Redis 集群实现方案 5. Redis 集群会有写操作丢失吗？为什么？ 6. Redis 慢查询是什么？通过什么配置？ 7. Redis 的慢查询修复经验有哪些？怎么修复的？ 8. 如何优化 Redis 服务的性能？ 9. Redis 的主从复制模式有什么优缺点? 10. Redis sentinel（哨兵）模式优缺点有哪些？ 11. 如何设置 Redis 的最大连接数？查看 Redis 的最大连接数？查看 Redis 的当前连接数？ 12. 介绍一些 Redis 常用的安全设置？ 二、Redis 缓存管理与持久化机制 1. Redis 持久化机制有哪些？ 2. Redis 持久化机制 AOF 和 RDB 有哪些不同之处？ 3. 请介绍一下 RDB 持久化机制的优缺点 4. 请介绍一下 AOF 持久化机制的优缺点 5. 如果 AOF 文件的数据出现异常， Redis 服务怎么处理？ 6. 常见的淘汰算法有哪些？ 7. Redis 淘汰策略有哪些？ 8. Redis 缓存失效策略有哪些？ 9. Redis 如何做内存优化？ 10. 什么是 bigkey？ 有什么影响？ 11.

很多小伙伴在学习Java的时候，总是感觉Java多线程在实际的业务中很少使用，以至于不会花太多的时间去学习，技术债不断累积！等到了一定程度的时候对于与Java多线程相关的东西就很难理解，今天需要探讨的东西也是一样的和Java多线程相关的！做好准备，马上开车！ 学过Java多线程的应该都知道什么是锁，没学过的也不用担心，Java中的锁可以简单的理解为多线程情况下访问临界资源的一种线程同步机制。 在学习或者使用Java的过程中进程会遇到各种各样的锁的概念：公平锁、非公平锁、自旋锁、可重入锁、偏向锁、轻量级锁、重量级锁、读写锁、互斥锁等。 蒙了吗？不要紧！即使你这些都不会也不要紧，因为这个和今天要探讨的关系不大，不过如果你作为一个爱学习的小伙伴，这里也给你准备了一份秘籍：《Java多线程核心技术》，一共19篇祝你一臂之力！免费版的不过瘾，当然也有收费版的！ 一、为什么要使用分布式锁 我们在开发应用的时候，如果需要对某一个共享变量进行多线程同步访问的时候，可以使用我们学到的Java多线程的18般武艺进行处理，并且可以完美的运行，毫无Bug！ 注意这是单机应用，也就是所有的请求都会分配到当前服务器的JVM内部，然后映射为操作系统的线程进行处理！而这个共享变量只是在这个JVM内部的一块内存空间！ 后来业务发展，需要做集群，一个应用需要部署到几台机器上然后做负载均衡，大致如下图： 上图可以看到

引自：https://blog.csdn.net/xlgen157387/article/details/79036337 很多小伙伴在学习Java的时候，总是感觉Java多线程在实际的业务中很少使用，以至于不会花太多的时间去学习，技术债不断累积！等到了一定程度的时候对于与Java多线程相关的东西就很难理解，今天需要探讨的东西也是一样的和Java多线程相关的！做好准备，马上开车！ 学过Java多线程的应该都知道什么是锁，没学过的也不用担心，Java中的锁可以简单的理解为多线程情况下访问临界资源的一种线程同步机制。 在学习或者使用Java的过程中进程会遇到各种各样的锁的概念：公平锁、非公平锁、自旋锁、可重入锁、偏向锁、轻量级锁、重量级锁、读写锁、互斥锁等。 蒙了吗？不要紧！即使你这些都不会也不要紧，因为这个和今天要探讨的关系不大，不过如果你作为一个爱学习的小伙伴，这里也给你准备了一份秘籍：《Java多线程核心技术》，一共19篇祝你一臂之力！免费版的不过瘾，当然也有收费版的！ 一、为什么要使用分布式锁 我们在开发应用的时候，如果需要对某一个共享变量进行多线程同步访问的时候，可以使用我们学到的Java多线程的18般武艺进行处理，并且可以完美的运行，毫无Bug！ 注意这是单机应用，也就是所有的请求都会分配到当前服务器的JVM内部，然后映射为操作系统的线程进行处理

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 随着币价的一直下跌，有传言说，比特币价格此次崩盘，只是大 BOSS 吴忌寒为加速淘汰老旧矿机而祭出的绝招。 无论这个阴谋论真假与否，在整个区块链行业的凛冽寒冬中，价格的涨跌已经左右了太多的人头脑之中的理智。可是，众人之中，究竟有几个人真正理解了区块链技术的密码学机制与分布式计算？究竟有几个人还会关心区块链在技术上的创新？ 尘归尘，土归土。可能只有巨大的泡沫消散之后，区块链才能通过技术创新显示出真正的影响力。让区块链回归技术与应用的本质，这也是我们一直以来的定位。然而，传播这样的内容和话题，离不开货真价实的技术干货，以及有感染力的人物和故事。 我们今天的内容就来自于这样一个女生： 她是工业与系统工程专业出身，做过顶级投行高盛的分析师，做过著名风投 a16z 的合伙人——这都是许多人梦寐以求的工作。但是，功成名就的路上，她却发现编程才是自己想要的生活。 笨办法学会编程？她没学会。如何用 HTML/CSS 做一个网页？她开始上瘾了。所以，没有选择斯坦福、MIT 的编程学位，她更喜欢 Hack Reactor 的全栈动手实践。先学 JavaScript、React，后面的想法是机器学习、计算机视觉……这个女生就是 Preethi Kasireddy。 接触区块链之后，金融从业背景和全栈编程能力让 Preethi

用户可以体验分布式NAS集群EonStor CS出色而稳定的性能，以及所具备的配置灵活性。本文针对一些客户的需求信息，提出设计解决方案所考虑的几个要点，以便满足客户的需求。 容量 在选择数据保护级别时，容量是最重要的因素之一。 客户一般会预先提供原始容量或可用容量的要求。 在Infortrend分布式文件系统中，我们采用纠删码/副本技术跨节点保护数据。对于看重容量的应用，建议用户通过纠删码来保护数据，因为纠删码在容量使用率上效果更好。 而特别强调数据关键性的应用程序，副本会更满足这类的需求。 EonStor CS还保留Infortrend RAID技术保护单个节点的数据，并且保持出色的性能以进行纵向扩展。 EonStor CS有3种RAID级别可供选择: 性能模式–在所有RAID模式中性能最高。 用户使用硬盘做RAID5。 平衡模式–用户使用硬盘做RAID5。但留下一颗或多颗盘做热备，这样提供更好的数据保护，并且也具备良好的容量使用情况。 保护模式–用户使用硬盘做RAID 6。在所有RAID模式中对数据的保护最高 用户可以最低部署1个节点的EonStorCS集群，获得最基本的保护级别（专用分布式文件系统），用户还可以将集群扩展到144个节点，进行横向扩展。CS纵向扩展时，有两种扩展柜规格可供使用：3U16盘位和4U60盘位。 一个节点最多可以连接3个3U 16盘的扩展柜

突发奇想，对于数据库，想到了一些有意思的事情和功能，算是对未来数据库发展的一种畅想吧，期待未来有实力的公司或是科研机构能真正实现。 一：分布式操作系统---永动机型操作系统 聊数据库，先要说说操作系统，毕竟数据库要安装部署在操作系统上。 目前应用服务常见的硬故障分为电源、CPU、硬盘、内存、网络等，这些都是常见的、不可抗拒的故障。非分布式操作系统下，各个服务器资源不能最大化的得到合理利用，即使是现在的K8S容器时代，也是这样。目前在应用服务层面，存在读写性能、CPU、内存、网络等瓶颈，但在分布式操作系统下的数据库将突破这些瓶颈，将实现永动机型的应用，永不宕机，资源足够的情况下，各种资源自动弹性伸缩，性能永远没有瓶颈，整体的资源也得到合理的利用，应用服务不再关心硬件问题。 目前实现了文件存储的分布式(如ceph等文件系统),但是还没有实现CPU、内存、网络的分布式，即使只实现文件系统的分布式，也带来了数据库的巨大变革，代表Aurora、PolarDB等，实现存储与计算分离，在硬件上，基本上不用在关注硬盘故障的问题，安全、性能和弹性扩展能力得到极大提升。 如果最主要的CPU、硬盘、内存、网络全部实现了真正的分布式，不再区分单机CPU、硬盘、内存、网络，所有的资源都在一个大池子中，所有分布式集群中的CPU和内存等资源是集群共有的、可以共享的，既可以限定使用服务资源使用

突发奇想，对于数据库，想到了一些有意思的事情和功能，算是对未来数据库发展的一种畅想吧，期待未来有实力的公司或是科研机构能真正实现。 一：分布式操作系统---永动机型操作系统 聊数据库，先要说说操作系统，毕竟数据库要安装部署在操作系统上。 目前应用服务常见的硬故障分为电源、CPU、硬盘、内存、网络等，这些都是常见的、不可抗拒的故障。非分布式操作系统下，各个服务器资源不能最大化的得到合理利用，即使是现在的K8S容器时代，也是这样。目前在应用服务层面，存在读写性能、CPU、内存、网络等瓶颈，但在分布式操作系统下的数据库将突破这些瓶颈，将实现永动机型的应用，永不宕机，资源足够的情况下，各种资源自动弹性伸缩，性能永远没有瓶颈，整体的资源也得到合理的利用，应用服务不再关心硬件问题。 目前实现了文件存储的分布式(如ceph等文件系统),但是还没有实现CPU、内存、网络的分布式，即使只实现文件系统的分布式，也带来了数据库的巨大变革，代表Aurora、PolarDB等，实现存储与计算分离，在硬件上，基本上不用在关注硬盘故障的问题，安全、性能和弹性扩展能力得到极大提升。 如果最主要的CPU、硬盘、内存、网络全部实现了真正的分布式，不再区分单机CPU、硬盘、内存、网络，所有的资源都在一个大池子中，所有分布式集群中的CPU和内存等资源是集群共有的、可以共享的，既可以限定使用服务资源使用

目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。 在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中， Java 中其实提供了很多并发处理相关的API，但是这些API在分布式场景中就无能为力了。也就是说单纯的 Java Api并不能提供分布式锁的能力。所以针对分布式锁的实现目前有多种方案。 针对分布式锁的实现，目前比较常用的有以下几种方案： 基于 数据库 实现分布式锁 基于缓存（ Redis ，memcached，tair）实现分布式锁 基于Zookeeper实现分布式锁 在分析这几种实现方案之前我们先来想一下，我们需要的分布式锁应该是怎么样的？（这里以方法锁为例，资源锁同理） 可以保证在分布式部署的应用集群中