集群服务器

1.1 keepalived高可用软件介绍 参考：haproxy: https://blog.csdn.net/l835311324/article/details/83031084 https://blog.csdn.net/qq_41772936/article/details/80718014 https://blog.51cto.com/3381847248/1977073 keepalive: https://blog.csdn.net/celeste7777/article/details/49096167 https://v3u.cn/a_id_117 　　1、keepalived--监控检查 　　　　　　注：keepalive软件有两种功能：监控检查、VRRP冗余协议 　　　　　　1. keepalive的作用是检测web服务器的状态，如果一台web服务器宕机，会将故障机器从集群中剔除 　　　　　　2. keepalieve会从以下三层来检查集群中的服务是否正常： 　　　　　　　　1） layer3： 通过ICMP协议ping测试 　　　　　　　　2） layer4： 比如web服务，keepalived检查80端口是否启动 　　　　　　　　3） layer7： 根据用户的设定检查服务器程序运行是否正常 　　2、keepalived--VRRP冗余协议原理 　　　　

前言 前几篇我们介绍了项目中 如何使用logback组件记录系统的日志情况 ；现在我们的系统都是分布式的，集群化的，那就代表着**我们的应用会分布在很多服务器上面；**那应用的日志文件就会分布在各个服务器上面。 问题 突然有一天我们系统出现了问题，我们第一时间想到的是 先要判断到底哪个服务出现了问题 ；我们的技术人员就连接生产环境服务器，查看服务器上面的应用日志。 那么多的服务器，技术人员这个时候就会很抓狂 ，一个个的查看分析日志，是比较愚蠢的方法。那有什么好的方式呢？今天老顾给大家介绍常规的方案。 ELK方案 ELK 是elastic公司提供的一套完整的日志收集以及展示的解决方案 ，是三个产品的首字母缩写，分别是ElasticSearch、Logstash 和 Kibana。 ElasticSearch简称ES ，它是一个 实时的分布式搜索和分析引擎 ，它可以用于全文搜索，结构化搜索以及分析。它是一个 建立在全文搜索引擎 Apache Lucene 基础上的搜索引擎 ，使用 Java 语言编写。 Logstash是一个具有实时传输能力的数据收集引擎 ，用来进行数据收集（如：读取文本文件）、解析，并将数据 发送给ES 。 Kibana为 Elasticsearch 提供了分析和可视化的 Web 平台 。它可以在 Elasticsearch 的索引中查找，交互数据，并生成各种维度表格

hadoop伪分布式安装笔记 参考 https://www.cnblogs.com/zhangyinhua/p/7647686.html https://blog.csdn.net/javastart/article/details/47187733 一、Hadoop的三种运行模式（启动模式） 1.1、单机模式（独立模式）（Local或Standalone Mode） 　　-默认情况下，Hadoop即处于该模式，用于开发和调式。 　　-不对配置文件进行修改。 　　-使用本地文件系统，而不是分布式文件系统。 　　-Hadoop不会启动NameNode、DataNode、JobTracker、TaskTracker等守护进程，Map()和Reduce()任务作为同一个进程的不同部分来执行的。 　　-用于对MapReduce程序的逻辑进行调试，确保程序的正确。 1.2、伪分布式模式（Pseudo-Distrubuted Mode） 　　-Hadoop的守护进程运行在本机机器，模拟一个小规模的集群　 　　-在一台主机模拟多主机。 　　-Hadoop启动NameNode、DataNode、JobTracker、TaskTracker这些守护进程都在同一台机器上运行，是相互独立的Java进程。 　　-在这种模式下，Hadoop使用的是分布式文件系统，各个作业也是由JobTraker服务

对于大数据集群来说，监控功能是非常必要的，通过日志判断故障低效，我们需要完整的指标来帮我们管理Kafka集群。本文讨论Kafka的监控以及一些常用的第三方监控工具。 一、Kafka Monitoring 首先介绍kafka的监控原理，第三方工具也是通过这些来进行监控的，我们也可以自己去是实现监控，官网关于监控的文档地址如下： http://kafka.apache.org/documentation/#monitoring ]( http://kafka.apache.org/documentation/#monitoring ) kafka使用Yammer Metrics进行监控，Yammer Metrics是一个java的监控库。 kafka默认有很多的监控指标，默认都使用JMX接口远程访问，具体方法是在启动broker和clients之前设置JMX_PORT： JMX_PORT=9997 bin/kafka-server-start.sh config/server.properties Kafka的每个监控指标都是以JMX MBEAN的形式定义的，MBEAN是一个被管理的资源实例。 我们可以使用Jconsole （Java Monitoring and Management Console），一种基于JMX的可视化监视、管理工具。 来可视化监控的结果： 图2

分布式：一个业务拆分为多个子业务，部署在多个服务器上 。 集群：同一个业务，部署在多个服务器上 。 转自： https://blog.csdn.net/jiangyu1013/article/details/80417961 来源： CSDN 作者： 周杰伦本人 链接： https://blog.csdn.net/sdaujsj1/article/details/104353457

分布式系统与高并发高可用 浅析分布式系统中的一致性哈希算法 通过本文将了解到以下内容： 分布式系统的简单概念和基本作用 分布式系统常用负载均衡策略 普通哈希取模策略优缺点 一致性哈希算法的定义和思想 一致性哈希的基本过程 Redis集群中一致性哈希的实现 1.分布式系统的基本概念 分布式系统与高并发高可用 当今高并发和海量数据处理等场景越来越多，实现服务应用的高可用、易扩展、短延时等成为必然。 在此情况下分布式系统应运而生，互联网的场景无外乎存储和计算，因此分布式系统可以简单地分为： 分布式存储 分布式计算 所谓分布式系统就是一批计算机组合起来共同对外提供服务，对于用户来说具体有多少规模的计算机完成了这次请求，完全是无感知的。分布式系统中的计算机越多，意味着计算和存储资源等也就越多，能够处理的并发访问量也就越大，响应速度也越快。 如图为简单整体架构图： 大前端 主要实现了服务应用对应的所有流量的接入，比如xyz域名下可能有N个子服务，这一层涉及很多网络流量的处理，也很有挑战，像百度的BFE(百度统一前端)接入了百度的大部分流量，每日转发1万亿次，峰值QPS1000w。 中间层 完成了各个服务的调度和分发，粒度相比大前端接入层更细致一些，这一层实现了用户的无感知体验，可以简单理解为反向代理层。 业务层 完成了数据存储、数据计算、数据缓存等，各个业务环节高度解耦，并且基于集群化来实现。

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

从各个角度总结了电商平台中的架构实践，由于时间仓促，定了个初稿，待补充完善，欢迎大家一起交流。 转载请声明出处： http://blog.csdn.net/yangbutao/article/details/12242441 作者：杨步涛 关注分布式架构、大数据、搜索、开源技术 QQ:306591368 技术Blog： http://blog.csdn.net/yangbutao 一、 设计理念 1. 空间换时间 1) 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag） 反向代理缓存 应用端的缓存(memcache) 内存数据库 Buffer、cache机制（数据库，中间件等） 2) 索引 哈希、B树、倒排、bitmap 哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 1) 任务切分、分而治之

从各个角度总结了电商平台中的架构实践，由于时间仓促，定了个初稿，待补充完善，欢迎大家一起交流。 转载请声明出处： http://blog.csdn.net/yangbutao/article/details/12242441 作者：杨步涛 关注分布式架构、大数据、搜索、开源技术 QQ:306591368 技术Blog： http://blog.csdn.net/yangbutao 一、 设计理念 1. 空间换时间 1) 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag） 反向代理缓存 应用端的缓存(memcache) 内存数据库 Buffer、cache机制（数据库，中间件等） 2) 索引 哈希、B树、倒排、bitmap 哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 1) 任务切分、分而治之

nacos 集群搭建 1，我在这三个服务器搭建nacos集群。后续搭建根据自己服务器的真实ip 10.19.161.196 10.19.161.197 10.19.161.239 2，在root的家目录下，建立 application 目录，然后把nacos解压到这里。 官方下载地址 cd ~ mkdir application cp ./software/nacos-server-1.1.4.tar.gz ./application/ cd application tar zxvf nacos-server-1.1.4.tar.gz 3，把cluster.conf.example改名为cluster.conf，并修改内容如下。后续搭建，根据真实ip填写。 #it is ip #example 10.19.161.196:8848 10.19.161.197:8848 10.19.161.239:8848 4，配置mysql数据源 修改 application.properties，添加下面的东西 spring.datasource.platform=mysql db.num=1 db.url.0=jdbc:mysql://10.19.161.239:3306/nacos_config?useUnicode=true&characterEncoding=UTF-8