分布式开发

1.Hadoop 　　a.概念：Hadoop是一个由Apache基金会所开发的分布式系统基础架构 　　b.组成：Hadoop = HDFS (文件系统) + Mapreduce (数据处理) 2.安装 　　a.配置Java运行环境 　　b.从官网下载 Hadoop 并解压，地址：http://hadoop.apache.org/releases.html 　　c.下载 winutils 对 windows 进行支持，地址：https://github.com/steveloughran/winutils（支持老版本） 　　　　　　　　　　　　　　　　　　　　　　https://github.com/zyj108/apache-hadoop-3.1.0-winutils（支持Hadoop3.1.2） 　　d.解压 winutils 覆盖到 Hadoop 根目录（主要是覆盖bin目录） 　　e.在 Hadoop 的 etc\hadoop 下，修改如下配置文件 　　　　①修改core-site.xml，配置默认hdfs的访问端口 <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9527</value> </property> </configuration> 　　　　②修改hdfs

自建商城在设计之初，业务部门就提出了两个要求： 不崩 & 快速上线。 在立项之后，团队还没有完全配备好，一边从其他团队里调取人手，一边大力招聘，与此同时，我们的架构师也在搭建一套分布式商城开发框架，编写 Demo，让新加入的同学能快速上手。 暴露问题 问题一： 分布式事务 为什么会使用分布式事务？ 这个暂且可以归因于快速上线，因为生成订单会调用到商品服务扣减库存，使用了分布式事务解决了因为跨服务调用引起库存超卖的问题，带来的问题就是性能上的消耗。 问题二： 数据库压力 在大促活动期间，有个实时统计是直接从业务库上直接查询统计的，运营部门的小姐姐在不断地刷新，导致该接口上的压力山大，而且没有使用缓存，连 SQL 查询条件的时间都是动态的，导致 DB 层的缓存也使用不上，每次请求都打到 DB 上。 开发和测试环境是使用自建的 MySQL，生产环境使用的是 PolarDB，从阿里云官网上看到： 集群架构，计算与存储分离 读写分离 我们主观地认为，只要我们使用了集群连接地址就会自动进行读写分离，但是实际上并没有，后来发现在方法上显式的指定只读事务就有请求走到只读节点上了。 @Transactional(readOnly = true) # 优化思路： 1）从 SQL 洞察和慢 SQL 里找调用响应时间最长和频度最高的 SQL； 2）结合代码，能用缓存代替的直接处理掉，不用能缓存的优化查询

架构设计（1）-谈谈架构 原创我为AI领域做了奉献 发布于2018-11-15 10:39:22 阅读数 419 收藏 展开 分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn.net/jiangjunshow 也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！ 1、什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。 LInux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 1.1、系统与子系统 系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。 子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。 1.2、模块与组件 都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。 1.3、框架与架构 框架是组建的规范，例如：MVC、MVP、MVVM等，是提供基础功能的产品，例如：Ruby on Rails、Spring、Laravel、Django等。 框架是规范，架构是结构。 我再这重新定义架构

简介 视图可以看作定义在SQL Server上的虚拟表.视图正如其名字的含义一样，是另一种查看数据的入口.常规视图本身并不存储实际的数据，而仅仅存储一个Select语句和所涉及表的metadata. 视图简单的理解如下: 通过视图，客户端不再需要知道底层table的表结构及其之间的关系。视图提供了一个统一访问数据的接口。 为什么要使用视图(View) 从而我们不难发现，使用视图将会得到如下好处: 视图隐藏了底层的表结构，简化了数据访问操作 因为隐藏了底层的表结构，所以大大加强了安全性，用户只能看到视图提供的数据 使用视图，方便了权限管理，让用户对视图有权限而不是对底层表有权限进一步加强了安全性 视图提供了一个用户访问的接口，当底层表改变后，改变视图的语句来进行适应，使已经建立在这个视图上客户端程序不受影响 视图(View)的分类 视图在SQL中可以分为三类 普通视图(Regular View) 索引视图(Indexed View) 分割视图(Partitioned View) 下面从这几种视图类型来谈视图 普通视图(Rugular View) 普通视图由一个Select语句所定义，视图仅仅包含其定义和被引用表的metadata.并不实际存储数据。MSDN中创建视图的模版如下: CREATE VIEW [ schema_name . ] view_name [ (column [ ,

一、缓存在系统中用来做什么 1. 少量数据存储，高速读写访问。通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。 2. 海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。Redis3.0以后开始支持集群，实现了半自动化的数据分片，不过需要smart-client的支持。 二、从不同的角度来详细介绍redis 网络模型：Redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和select，对于单纯只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型实际会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。 内存管理：Redis使用现场申请内存的方式来存储数据，并且很少使用free-list等方式来优化内存分配，会在一定程度上存在内存碎片，Redis跟据存储命令参数，会把带过期时间的数据单独存放在一起，并把它们称为临时数据，非临时数据是永远不会被剔除的，即便物理内存不够，导致swap也不会剔除任何非临时数据（但会尝试剔除部分临时数据），这点上Redis更适合作为存储而不是cache。 数据一致性问题：在一致性问题上

一、简介 1.1　概述 Kafka是最初由Linkedin公司开发，是一个 分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统） ，常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。 主要应用场景是： 日志收集系统和消息系统。 Kafka主要设计目标如下： 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。 同时支持离线数据处理和实时数据处理。 Scale out:支持在线水平扩展 1.2　消息系统介绍 一个消息系统负责将数据从一个应用传递到另外一个应用，应用只需关注于数据，无需关注数据在两个或多个应用间是如何传递的。分布式消息传递基于可靠的消息队列，在客户端应用和消息系统之间异步传递消息。有两种主要的消息传递模式：点对点传递模式、发布-订阅模式。大部分的消息系统选用发布-订阅模式。 Kafka就是一种发布-订阅模式。 1.3　点对点消息传递模式 在点对点消息系统中，消息持久化到一个队列中。此时

分布式追踪系统 使用 Zipkin 和 Brave 实现分布式系统追踪（基础篇） - 推酷 OpenZipkin · A distributed tracing system Twitter zipkin 分布式跟踪系统的设计与实现 - 马宏的世界 - 博客频道 - CSDN.NET openzipkin/brave: Java distributed tracing implementation compatible with Zipkin backend services. openzipkin/zipkin: Zipkin is a distributed tracing system zipkin - liaokailin的专栏 - 博客频道 - CSDN.NET #研发解决方案介绍#Tracing（鹰眼） - 旁观者 - 博客园 分布式系统为什么需要 Tracing？ 先介绍一个概念： 分布式跟踪 ，或 分布式追踪 。 电商平台由数以百计的分布式服务构成，每一个请求路由过来后，会经过多个业务系统并留下足迹，并产生对各种Cache或DB的访问，但是这些分散的数据对于问题排查，或是流程优化都帮助有限。对于这么一个跨进程/跨线程的场景，汇总收集并分析海量日志就显得尤为重要。 要能做到追踪每个请求的完整调用链路，收集调用链路上每个服务的性能数据，计算性能数据和比对性能指标（SLA

ZooKeeper是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper通过其简单的架构和API解决了这个问题。ZooKeeper允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。 ZooKeeper框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。 后来，Apache ZooKeeper成为Hadoop，HBase和其他分布式框架使用的有组织服务的标准。 例如，Apache HBase使用ZooKeeper跟踪分布式数据的状态。 先来介绍一下分布式： 分布式应用 分布式应用可以在给定时间（同时）在网络中的多个系统上运行，通过协调它们以快速有效的方式完成特定任务。通常来说，对于复杂而耗时的任务，非分布式应用（运行在单个系统中）需要几个小时才能完成，而分布式应用通过使用所有系统涉及的计算能力可以在几分钟内完成。 通过将分布式应用配置为在更多系统上运行，可以进一步减少完成任务的时间。分布式应用正在运行的一组系统称为 集群 ，而在集群中运行的每台机器被称为 节点 。 分布式应用有两部分， Server（服务器） 和 Client（客户端） 应用程序。服务器应用程序实际上是分布式的，并具有通用接口，以便客户端可以连接到集群中的任何服务器并获得相同的结果。

2019最新JAVA架构师视频资料，搭建高并发，高并发解决方案，高可用电商架构视频教程分布式框架,高可用框架,微服务架构,数据库优化39套Java架构师，高并发，高性能，高可用，分布式，集群，电商，缓存，微服务，微信支付宝支付，公众号开发，java8新特性，P2P金融项目，程序设计，功能设计，数据库设计，第三方支付，web安全，性能调优，设计模式，数据结构，并发编程，虚拟机，中间件，数据库，项目实战，大型分布式电商项目实战视频教程 视频课程包含： 39套包含：架构师，高并发，高性能，高可用，高可扩展，分布式，集群，电商，缓存，微服务，微信支付宝支付，公众号开发，java8新特性，P2P金融项目，程序设计，功能设计，数据库设计，架构设计，web安全，性能调优，设计模式，数据结构，项目实战，工作流，程序调优，负载均衡，Solr集群与应用，主从复制，中间件，全文检索，任务调度，jvm虚拟机，Spring boot，Spring cloud，Docker，Kubernetes，jvm，Dubbo，Elasticsearch，ActiveMQ，Rocketmq，Rabbitmq，Kafka，Mycat，Spring，Git，Nosql，Mecached，Netty，Nio，Mina，Nutch，Webservice，Activiti，Shiro，Tomcat，Mysql，Oracle

我们公司性质是新零售，公司也有专门的框架组。这群大牛自己开发了一整套分布式微服务框架。我们也在使用这套框架，有很多心得体会。 该框架既Dapeng也！开源github地址： https://github.com/dapeng-soa Dapeng-soa 是一个轻量级、高性能的微服务框架，构建在Netty以及定制的精简版Thrift之上。 同时，从Thrift IDL文件自动生成的服务元数据信息是本框架的一个重要特性，很多其它重要特性都依赖于服务元数据信息。 最后，作为一站式的微服务解决方案，Dapeng-soa还提供了一系列的脚手架工具以支持用户快速的搭建微服务系统，例如: 除部署需要吐槽外，好用地方如下： api网关( dapeng-mesh ), 提供基于服务元数据以及流式处理的Json模块用于处理http-json请求跟Thrift协议之间的相互转换。 在线文档以及测试站点( dapeng-api-doc )，直接基于服务元数据生成，确保跟代码保持同步。 命令行工具( dapeng-cli )，提供命令行或者脚本的方式跟服务集群交互，可用于服务运行时状态监控、数据修复等。 配置部署中心( dapeng-config-server )，提供web-gui界面，用于服务配置管理以及服务部署管理。 maven/sbt插件 for IDEA, 用于在开发过程中快速启动服务容器