集群技术

文档结构如下： 前言： Oracle 官方文档对索引的描述真是弱透了，对索引的说明就是一坨……，support也没有很好的资料，下面还是用的官方上的内容经过自己的整理加上网上的资料；至于为什么用索引，以及索引的重要性，相信大家都知晓；如果把数据库所有的表比如成一本书，那么，索引就是书的目录，你不可能每一次查看书的内容从第一页读到最后一页，不用目录吧！！ 索引类型： 索引是与表和群集关联的可选结构，可以使SQL查询对表执行得更快。正如本手册中的索引可以帮助您更快地找到信息（没有索引）一样，Oracle数据库索引提供了对表数据的更快访问路径。您可以使用索引而无需重写任何查询。结果是相同的，但是可以更快地看到它们。 Oracle数据库提供了几种索引方案，这些方案提供了互补的性能功能。这些是： B树索引：默认索引和最常见索引 B树集群索引：专门为集群定义 哈希集群索引：专门为哈希集群定义 全局和局部索引：与分区表和索引有关 反向键索引：对Oracle Real Application Clusters应用程序最有用 位图索引：紧凑；最适合具有少量值的列 基于函数的索引：包含函数/表达式的预先计算的值 域索引：特定于应用程序或盒带。 索引在逻辑上和物理上独立于关联表中的数据。作为独立的结构，它们需要存储空间。您可以创建或删除索引，而不会影响基表，数据库应用程序或其他索引。当您插入

导读 本文转载自MySQL解决方案工程师 作者：徐铁韬 这篇文章将详细地介绍MySQL的高可用解决方案—— MySQL InnoDB Cluster。 说到高可用性，首先要了解一下什么是高可用性？ 高可用性要求的实际上是对可靠性的要求，从本质上来说，是通过技术和工具来提高可靠性，尽可能长时间保持数据的可用和系统的正常运行时间。实现高可用性的原则为排除单点故障、通过冗余实现快速恢复，并且具有容错机制。 上面一页主要介绍了几个关键词汇，以及相关的定义，这些有助于理解可靠性和高可用性。 MySQL的高可用性解决方案目前大致分为5种，按照高可用的级别（99.9999%为最高级）排序依次为，主从复制、具有自动故障转移功能的主从复制、利用共享存储、OS或虚拟化软件实现主备架构、MySQL Group Replication 群组复制，以及MySQL NDB Cluster。 MySQL Replication：允许数据从一台实例上复制到一台或多台其它的实例上。 MySQL Group Replication：群组复制提供更好的冗余性、自动恢复以及写入扩展。 MySQL InnoDB Cluster：基于群组复制，提供了易于管理的API、应用故障转移和路由、易于配置，提供比群组复制更高级别的可用性。 MySQL NDB Cluster：容易与MySQL InnoDB Cluster混淆

设计理念 1 时间换空间 1.1 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag）， 反向代理缓存，应用端的缓存(memcache)，内存数据库，Buffer、cache机制（数据库，中间件等）。 1.2 索引 哈希、B树、倒排、bitmap 哈希索引:适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引:适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引:实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap:是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 2.1 任务切分、分而治之(MR) 在大规模的数据中，数据存在一定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。 MR模型是无共享的架构，数据集分布至各个节点。处理时，每个节点就近读取本地存储的数据处理(map)，将处理后的数据进行合并(combine)、排序(shuffle and sort)后再分发(至reduce节点)，避免了大量数据的传输，提高了处理效率。 2.2 多进程

作者：张sir 来源：京东技术（id：jingdongjishu） 1. 背景 　　京东到家订单中心系统业务中，无论是外部商家的订单生产，或是内部上下游系统的依赖，订单查询的调用量都非常大，造成了订单数据读多写少的情况。 　　京东到家的订单数据存储在Mysql中，但显然只通过DB来支撑大量的查询是不可取的，同时对于一些复杂的查询，Mysql支持得不够友好，所以订单中心系统使用了Elasticsearch来承载订单查询的主要压力。 　　Elasticsearch 做为一款功能强大的分布式搜索引擎，支持近实时的存储、搜索数据，在京东到家订单系统中发挥着巨大作用，目前订单中心ES集群存储数据量达到10亿个文档，日均查询量达到5亿。 　　随着京东到家近几年业务的快速发展，订单中心ES架设方案也不断演进，发展至今ES集群架设是一套实时互备方案，很好的保障了ES集群读写的稳定性，下面就给大家介绍一下这个历程以及遇到的一些坑。 2. ES集群架设演进历程 2.1 初始阶段 　　订单中心ES初始阶段好如一张白纸，架设方案基本没有，很多配置都是保持集群默认配置。整个集群部署在集团的弹性云上，ES集群的节点以及机器部署都比较混乱。同时按照集群维度来看，一个ES集群会有单点问题，显然对于订单中心业务来说也是不被允许的。 2.2 集群隔离阶段 　　和很多业务一样，ES集群采用的混布的方式

现在MapReduce/Hadoop以及相关的数据处理技术非常热，因此我想在这里将MapReduce的优势汇总一下，将MapReduce与传统基于HPC集群的并行计算模型做一个简要比较，也算是对前一阵子所学的MapReduce知识做一个总结和梳理。 引言 随着互联网数据量的不断增长，对处理数据能力的要求也变得越来越高。当计算量超出单机的处理能力极限时，采取并行计算是一种自然而然的解决之道。在MapReduce出现之前，已经有像MPI这样非常成熟的并行计算框架了，那么为什么Google还需要MapReduce，MapReduce相较于传统的并行计算框架有什么优势，这是本文关注的问题。 文章之初先给出一个传统并行计算框架与MapReduce的对比表格，然后一项项对其进行剖析。 传统 MapReduce 集群架构/容错性 共享式（共享内存/共享存储），容错性差 无共享式，容错性好 硬件/价格/扩展性 刀片服务器、高速网、SAN，价格贵，扩展性差 普通PC机（便宜），便宜，扩展性好 编程/学习难度 what+how，难 what，简单 适用场景 实时、细粒度计算、计算密集型 批处理、非实时、数据密集型 集群架构/容错性 在传统的并行计算中，计算资源通常展示为一台逻辑上统一的计算机。对于一个由多个刀片、SAN构成的HPC集群来说，展现给程序员的仍旧是一台计算机

第6章 DataNode（面试开发重点） 6.1 DataNode工作机制 6.2 数据完整性 6.3 掉线时限参数设置 6.4 服役新数据节点 6.5 退役旧数据节点 6.5.1 添加白名单 6.5.2 黑名单退役 6.6 Datanode多目录配置 第7章 HDFS 2.X新特性 7.1 集群间数据拷贝 7.2 小文件存档 7.3 回收站 7.4 快照管理 第6章 DataNode（面试开发重点） 6.1 DataNode工作机制 DataNode工作机制，如下图所示。 1）一个数据块在DataNode上以文件形式存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括 数据块的长度 ， 块数据的校验和 ，以及 时间戳 。 2）DataNode启动后向NameNode注册，通过后，周期性（1小时）的向NameNode上报所有的块信息。 3）心跳是每3秒一次，心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器，或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳，则认为该节点不可用。 4）集群运行中可以安全加入和退出一些机器。 6.2 数据完整性    思考： 如果电脑磁盘里面存储的数据是控制高铁信号灯的红灯信号（1）和绿灯信号（0），但是存储该数据的磁盘坏了，一直显示是绿灯，是否很危险？同理DataNode节点上的数据损坏了

kubernetes(k8s)容器编排工具基础概念 Kubernetes (K8s)： 　　中文社区： https://www.kubernetes.org.cn/replication-controller-kubernetes 　　官网： https://kubernetes.io/ 　　是一个开源系统，用于容器化应用的自动部署、扩缩和管理。Kubernetes 将构成应用的容器按逻辑单位进行分组以便于管理和发现。 　　Kubernetes 基于 谷歌公司在运行生产负载上的 15 年经验 打造，并融合了来自社区的最佳建议与实践。我们先来看看他的架构图： 　　要使用 Kubernetes，你需要用 Kubernetes API 对象 来描述集群的 预期状态（desired state） ：包括你需要运行的应用或者负载，它们使用的镜像、副本数，以及所需网络和磁盘资源等等。你可以使用命令行工具 kubectl 来调用 Kubernetes API 创建对象，通过所创建的这些对象来配置预期状态。你也可以直接调用 Kubernetes API 和集群进行交互，设置或者修改预期状态。 　　一旦你设置了你所需的目标状态，Kubernetes 控制面（control plane） 会通过 Pod 生命周期事件生成器( PLEG )，促成集群的当前状态符合其预期状态。为此，Kubernetes

本文所有相关链接pdf： https://163.53.94.133/assets/uploads/files/tf-ceg-case3.pdf Kubernetes命名空间是“虚拟化”Kubernetes集群的一种内置方式。虽然目前尚无人讨论如何使用命名空间以及在何处使用命名空间，但是如果没有网络范围内的命名空间隔离能力，集群虚拟化将无法完成。 Tungsten Fabric Kubernetes CNI插件包括对isolated命名空间的支持。部署到隔离的命名空间中的应用程序无法访问其所在的命名空间之外的任何Pod，其他命名空间的应用程序也无法访问它的Pod和Services。 使用场景 一种Kubernetes的部署方法，是每个开发团队部署单独的Kubernetes集群，在这种情况下，集群虚拟化和命名空间隔离几乎没有好处。 但是，由于未使用的容量是零散的，因此该方法可能导致资源使用效率低下。每个集群都有自己的可用容量，其他集群中运行的应用程序无法使用这些可用容量。此外，随着集群数量的增加，它引入了保持统一所需要的操作开销。最后，启动新集群需要花费时间，这可能会使事情变慢。 命名空间是解决这些问题的好方法，因为这有助于减少集群的数量，共享备用容量并且可以快速创建。这还可以提供一个隔离级别，基础架构团队将负责集群的管理，而各个开发人员团队则在自己的命名空间中进行操作。

作者 | 声东 阿里云售后技术专家 导读 ：阿里云售后技术团队的同学，每天都在处理各式各样千奇百怪的线上问题。常见的有网络连接失败、服务器宕机、性能不达标及请求响应慢等。但如果要评选的话，什么问题看起来微不足道事实上却让人绞尽脑汁，我相信肯定是“删不掉”的问题，比如文件删不掉、进程结束不掉、驱动卸载不了等。这样的问题就像冰山，隐藏在它们背后的复杂逻辑，往往超过我们的预想。 背景 今天我们讨论的这个问题，跟 K8s 集群的 Namespace 有关。Namespace 是 K8s 集群资源的“收纳”机制。我们可以把相关的资源“收纳”到同一个 Namespace 里，以避免不相关资源之间不必要的影响。 Namespace 本身也是一种资源。通过集群 API Server 入口，我们可以新建 Namespace，而对于不再使用的 Namespace，我们需要清理掉。Namespace 的 Controller 会通过 API Server，监视集群中 Namespace 的变化，然后根据变化来执行预先定义的动作。 有时候，我们会遇到下图中的问题，即 Namespace 的状态被标记成了 "Terminating"，但却没有办法被完全删除。 从集群入口开始 因为删除操作是通过集群 API Server 来执行的，所以我们要分析 API Server 的行为。跟大多数集群组件类似，API

架构设计 1 技术架构 RocketMQ架构上主要分为四部分，如上图所示: Producer：消息发布的角色，支持分布式集群方式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。 Consumer：消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制，可以满足大多数用户的需求。 NameServer：NameServer是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper，支持Broker的动态注册与发现。主要包括两个功能：Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；路由信息管理，每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。NameServer通常也是集群的方式部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息