分布式部署

一、什么是消息未读 消息未读包括 会话未读 和 总未读 。前者指的是当前用户和某一聊天方的未读消息数，后者指的是当前用户的所有未读消息数，也就是所有会话未读的和。比如用户A收到用户B的2条消息，还收到用户C的3条消息，则用户A与B的会话未读数是2，用户A与C的会话未读数是3，用户A的总未读是5。 二、消息未读的维护 会话未读和总未读数一般都是单独维护的。这是因为： 1）总未读的使用场景较多，会被高频使用。如APP角标未读展示； 2）如果不单独维护，则总未读数需要通过计算所有的会话未读数，一旦会话数较多，就需要多次读取存储，多次获取累加的操作容易出现性能瓶颈。而且一旦发生超时等意外，就会无法获取到会话未读数，导致总未读数不准确。 三、消息未读的一致性 单独维护总未读和会话未读数会带来新问题，也就是消息总未读数与（多个）会话未读数不一致的问题。比如APP角标显示5，表示有5条未读消息，但用户点进去却发现没有新消息或只有3条消息，就会给用户造成不好的体验。 消息未读不一致的原因 用户B的初始状态：会话未读数和总未读数都是0。 用户A给用户B发消息，消息到达IM服务后，执行加未读操作：先把用户B与用户A的会话未读数加1，再把用户B的总未读数加1，然后消息推送给用户B。 case1 ：假设加会话未读数的操作成功、加总未读数的操作失败了，则用户B的最新状态是：会话未读数是1，总未读数是0。

一. ELK 分布式日志实战介绍 　　此实战方案以 Elk 5.5.2 版本为准，分布式日志将以下图分布进行安装部署以及配置。 　　当Elk需监控应用日志时，需在应用部署所在的服务器中，安装Filebeat日志采集工具，日志采集工具通过配置，采集本地日志文件，将日志消息传输到Kafka集群， 我们可部署日志中间服务器，安装Logstash日志采集工具，Logstash直接消费Kafka的日志消息，并将日志数据推送到Elasticsearch中，并且通过Kibana对日志数据进行展示。 二、ELK安装部署开始 　　大家安装部署之前，可先参考官方文档进行部署。（官方参考文档地址可点击一下超链接） 　　注：Elasticsearch 6.4.0 默认安装了x-pack 安全插件，该插件授权 30天试用。（如过期，则自行选择购买，或者破解，本方案不提供破解方案） 　　 Elasticsearch 6.4.0 Kibana 6.4.0 Logstash 6.4.0 Filebeat 6.4.0 　 1、安装 Elasticsearch 　　 1.1、下载安装Elasticsearch 6.4.0 wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.4.0.tar.gz wget https:/

一、RPC RPC（Remote Process Call），即远程服务调用，被广泛地应用在很多企业应用中，是早期主要的服务治理方案，其流程较为简单，客户端consumer携带参数发送RPC请求到服务提供方provider，provider根据参数路由到具体函数，方法，并将执行获得的结果返回，至此一次RPC调用完成。 　　随着业务的发展，大数据时代的到来，服务提供方的压力也日益增大，单机应用的处理能力无论在软件，硬件上都受到限制，provider也不可能一直无限扩容，即使扩容，也存在着很多问题，即服务的路由，和Consumer的负载均衡问题。因此，分布式服务架构应运而生，RPC发展到一定阶段思考的变革，成为了分布式服务，云计算的计算机基础。 二、SOA 由于简单的RPC调用已经不能随着时代发展满足需求，因此复杂的业务逻辑对于分布式应用架构体系的需求愈发强烈，业务希望自己的服务是分布式部署的，请求是分流的，对数据的操作是能读写分离的，同时能屏蔽许多复杂需要自己编写的底层服务，借助已有的公共服务，去快速的构建自己的应用，降低人力开发维护的成本和提高应用交付的效率，基因此，基于分布式服务思想的SOA（Service-Oriented Architecture）成了新的受追捧的架构。常见的SOA服务调用流程图如下：　 三、业界服务治理方案 业界的互联网巨头公司，都有属于自己的分布式服务框架

大型分布式系统原理概述 分布式系统三要素 ​ CPU:处理器 ​ Memory:内存 ​ IO:外存 ​ MultiCore:多核心 ​ LocalDisk:本地磁盘 ​ Networker:网络，网络存储 ​ RDMA:远程内存直接访问 ​ NUMA:分布式系统CPU和内存进行整合，对内存进行捆绑，是硬件层级的，（相似与ThreadLocal,将数据和实时运行线程绑定到一起），网卡直接绕过CPU共享内存，速度非常快 ​ 分布式系统三要素的进化 ​ 桌面级八核心十六线程CPU于2014年诞生，2015年Intel预计发布18核心桌面级CPU ​ NUMA在大中型系统上一直非常盛行，NUMA能很好提升系统吞吐能力，特别对于Java以及数据这样占用大内存的系统，但一直以来没有得到 DBA 们足够的重视、 Java领域也很少有人研究 ​ RDMA（远程内存直接访问，网络传输协议，类似TCP,更低延迟）是超高性能计算UHPC的重要基础之一，而Direct Socket Protocol （SDP）作为RDMA的传输协议已经在很多关键领域取代了TCP，Java7也正式开始支持SDP，跨入了UHPC的领地。 ​ IO方面，万兆网正在崛起，万兆网的ISCSI存储， 单通道可达到500MB/s， 每秒500,000个IO能力，而目前主流的SSD硬盘的速度是400-550MB/s。 ​ ===

【背景】 随着单体应用的缺陷日益明显，越多越多的公司都从传统的单体应用模式向新型的分布式应用模式转变。 实际上，在分布式应用带来巨大优势的同时，也伴随着各种挑战。例如，系统容错、网络延迟和分布式事务等。 本篇博客开始，将会对分布式事务做一系列学习总结。从本篇博客，我们可以了解到什么是分布式事务，关于分布式事务的相关理论以及处理分布式事务的解决方案。 【本地事务】 在没有接触分布式应用前，我们接触到的事务一般都是本地事务，即在单个数据库并且限制在单个进程内的事务。本地事务不涉及多个数据源。 若我们的系统使用了spring，一般加上@Transition注解即可保证事务正常运行。但如果是分布式系统应用下，若操作涉及不同的数据库，这样本地事务就失效了，从而就涉及到了分布式事务。 【分布式事务】 1. 什么是分布式事务 分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2. 分布式事务的产生原因 从原来的单体应用到分布式应用的转变，便意味着从以前的一个系统到多个服务共同组成一个系统的转变。 如一个电商系统，拆分为订单

背景：调度机在windows环境，两台执行机在linux环境 linux环境上传《jdk-8u181-linux-x64.tar》和《apache-jmeter-4.0.zip》安装包 1.安装jdk tar -xzf jdk-8u181-linux-x64.tar，生成文件夹 jdk1.8.0 配置java环境变量 1）vi /etc/profile，在最后面增加两行 export JAVA_HOME=/usr/local/jdk1.8.0_144 export PATH=$JAVA_HOME/bin:$PATH 2）执行命令：source /etc/profile，无需重启，配置的环境变量立马生效 3）查看是否安装成功，执行命令：java -version 2.安装jmeter 将本地的Jmeter文件打包成zip文件：apache-jmeter-4.0.zip，再上传到服务器/usr/local 在服务器解压缩，生成apache-jmeter-4.0目录 配置Jmeter环境变量。 1）vi /etc/profile，再添加如下变量 export JMETER_HOME=/usr/local/apache-jmeter-4.0 export CLASSPATH=$JMETER_HOME/lib/ext/ApacheJMeter_core.jar:$JMETER_HOME

原地址：http://bigdata.idcquan.com/dsjjs/159544.shtml 大数据 技术的体系庞大且复杂，基础的技术包含数据的采集、数据预处理、分布式存储、NoSQL数据库、数据仓库、机器学习、并行计算、可视化等各种技术范畴和不同的技术层面。首先给出一个通用化的大数据处理框架，主要分为下面几个方面：数据采集与预处理、数据存储、数据清洗、数据查询分析和数据可视化。 一、数据采集与预处理 对于各种来源的数据，包括移动互联网数据、社交网络的数据等，这些结构化和非结构化的海量数据是零散的，也就是所谓的数据孤岛，此时的这些数据并没有什么意义，数据采集就是将这些数据写入数据仓库中，把零散的数据整合在一起，对这些数据综合起来进行分析。数据采集包括文件日志的采集、数据库日志的采集、关系型数据库的接入和应用程序的接入等。在数据量比较小的时候，可以写个定时的脚本将日志写入存储系统，但随着数据量的增长，这些方法无法提供数据安全保障，并且运维困难，需要更强壮的解决方案。 Flume NG作为实时日志收集系统，支持在日志系统中定制各类数据发送方，用于收集数据，同时，对数据进行简单处理，并写到各种数据接收方(比如文本，HDFS，Hbase等)。Flume NG采用的是三层架构：Agent层，Collector层和Store层，每一层均可水平拓展。其中Agent包含Source

Zk是一个分布式服务框架，提供了协调分布式应用的基本服务，zk集群主要是保证服务的可靠性和稳定性，介绍一下集群的安装与配置，在安装之前需要安装好jdk，jdk的安装请网上查找相应的方法 Dubbo 注册中心集群Zookeeper-3.4.6 Dubbo建议使用Zookeeper作为服务的注册中心。 Zookeeper集群中只要有过半的节点是正常的情况下，那么整个集群对外就是可用的。正是基于这个特性，要将ZK集群的节点数量要为奇数（2n+1：如3、5、7个节点）较为合适。 ZooKeeper 与Dubbo服务集群架构图 服务器1：192.168.1.81 端口：2181、2881、3881 服务器2：192.168.1.82 端口：2182、2882、3882 服务器3：192.168.1.83 端口：2183、2883、3883 1、 修改操作系统的/etc/hosts文件，添加IP与主机名映射： # zookeeper clusterservers 192.168.1.81 edu-zk-01 192.168.1.82 edu-zk-02 192.168.1.83 edu-zk-03 2、 下载或上传zookeeper-3.4.6.tar.gz到/home/wusc/zookeeper目录： $ cd /home/wusc/zookeeper $ wget http:/

01分布式缓存概览 使用原因 为什么要使用分布式缓存，很简单的一点你当前的系统性能已经不适用于你的业务量就不得不升级你的系统提高系统性能，从哪几个方面提高，优化代码，优化数据库，使用静态数据，只有在单机已经没有办法满足业务的情况下才会去考虑集群然后才是分布式 分布式意味着你要将原来的系统拆分成多个服务，这就涉及到服务之间的调用以及数据的一致性问题。将单机变为分布式以后，系统的性能并发有了足够的提升但是数据库的压力大了起来大量的数据库I/O操作消耗大量的资源。怎么减轻数据库的压力，把从磁盘读的 数据放到内存减少磁盘I/O操作也就是缓存，把缓存分到多台服务器就是分布式缓存。 应用场景 01-页面缓存 我们在访问某一个网站的时候，请求发送到后台，后台从数据库查询到数据后并进行渲染之后返回，这个过程的资源消耗在数据的读取和渲染，所以需要在进入读数据之前从缓存中找缓存中没有再从数据库查询渲染并存入缓存 02-状态缓存 解决分布式Web部署的session同步问题，状态缓存.缓存包括Session 会话状态及应用横向扩展时的状态数据等,这类数据一般是难以恢复的,对可用性要求较高。 03-并行处理 分布式计算中，中间数据的共享问题 04-事务处理 分布式事务的数据在缓存与数据库中的一致性问题 06-热点数据 在并发量大的系统中，访问频率高的热点数据 应用技术 07-Ehcache

随着网站的功能和用户越来越多，单机器服务部署的Web应用已经不能再支持了。这时候就需要优化或调整目前的架构，具体怎么优化，或先优化哪部分，这取决于网站的具体情况， 并非总是一个套路。 如根据使用情况得知，数据库压力大，则就可以先设施读写分离，分库分表，是垂直划分(可以简单的理解为按业务功能划分)， 还是水平划分(如用户表数据量很多，就可以按一定的规则分表设计,表结构仍然是相同的)。如Web应用服务器压力大,可以增加一台服务部署应用， 即从单台服务变为集群。变为集群后，用户访问网站，到底是选择哪一台服务器呢？这就需要在应用服务器前增加负载均衡设备来解决。还有点就是会话session 管理的问题，接下来会详细说明这问题。 具体的问题 当一个带有会话表示的Http请求到Web服务器后，需求在请求中的处理过程中找到session数据。而问题就在于，session是保存在单机上的。 假设我们有应用A和应用B，现在一位用户第一次访问网站，session数据保存在应用A中。如果我们不做处理，怎么保障接下来的请求每次都请求到应用A呢? 如请求到了应用B中，就会发现没有这位用户的session数据，这绝对是不能容忍的。 解决方案 解决方案有Session Stick，Session复制，Session集中管理，基于Cookie管理，下面一一说明。 Session Stick 在单机情况