分布式技术

不知道你是否遇到过这样的情况，去小卖铺买东西，付了钱，但是店主因为处理了一些其他事，居然忘记你付了钱，又叫你重新付。又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易。 知识脑图： 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。 数据库本地事务 ACID 说到数据库事务就不得不说，数据库事务中的四大特性，ACID: A:原子性(Atomicity) 一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 就像你买东西要么交钱收货一起都执行，要么要是发不出货，就退钱。 C:一致性(Consistency) 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用

#0 系列目录# 大型分布式网站架构 大型分布式网站架构技术总结 本文是学习大型分布式网站架构的技术总结。对架构一个高性能，高可用，可伸缩，可扩展的分布式网站进行了概要性描述，并给出一个架构参考。一部分为读书笔记，一部分是个人经验总结。对大型分布式网站架构有很好的参考价值。 #1 大型网站的特点# 用户多，分布广泛 大流量，高并发 海量数据，服务高可用 安全环境恶劣，易受网络攻击 功能多，变更快，频繁发布 从小到大，渐进发展 以用户为中心 免费服务，付费体验 #2 大型网站架构目标# 高性能：提供快速的访问体验。 高可用：网站服务一直可以正常访问。 可伸缩：通过硬件增加/减少，提高/降低处理能力。 安全性：提供网站安全访问和数据加密，安全存储等策略。 扩展性：方便的通过新增/移除方式，增加/减少新的功能/模块。 敏捷性：随需应变，快速响应； #3 大型网站架构模式# 分层：一般可分为，应用层，服务层，数据层，管理层，分析层； 分割：一般按照业务/模块/功能特点进行划分，比如应用层分为首页，用户中心。 分布式：将应用分开部署（比如多台物理机），通过远程调用协同工作。 集群：一个应用/模块/功能部署多份（如：多台物理机），通过负载均衡共同提供对外访问。 缓存：将数据放在距离应用或用户最近的位置，加快访问速度。 异步：将同步的操作异步化。客户端发出请求，不等待服务端响应

一般来说，构建分布式系统的目的一是增加系统容量，二是提高系统的可用性。转换成技术方面，也就是宛成以下两件事。 大流量处理。通过集群技术把大规模并发请求的负载分散到不同的机器上 关键业务保护。提高后台服务的可用性，把故障隔离起来阻止多米诺骨牌效应（雪崩效应）。如果流量过大，需要到业务降级。 说白了就是干两件事，一是提高整体架构的吞吐量，服务更多的并发和流量，二是提高系统的稳定性，让系统的可用性更高。 提高架构的性能 提高架构的稳定性 分布式系统的关键技术 引入分布式系统，会引入一堆技术问题，需要从以下几个方面解决 服务治理。服务拆分、服务调用、服务发现，服务依赖，服务的关键度定义……服务治理的最大意义是需要把服务间的依赖关系、服务调用链，以及关键的服务给梳理出来，并对这些服务进行性能和可用性方面的管理。 架构软件管理。服务之间有依赖，而且有兼容性问题，所以，整体服务所形成的架构需要有架构版本管理、整体架构的生命周期管理，以及对服务的编排、聚合、事务处理等服务调度功能。 DevOps。分布式系统可以更为快速地更新服务，但是对于服务的测试和部署都会是挑战。所以，还需要 DevOps 的全流程，其中包括环境构建、持续集成、持续部署等。 自动化运维。有了 DevOps 后，我们就可以对服务进行自动伸缩、故障迁移、配置管理、状态管理等一系列的自动化运维技术了。 资源调度管理

原文地址： http://www.sohu.com/a/228804309_99940985 我们很高兴地宣布，今天 蚂蚁金服启动分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA 中间件）的开源计划！ SOFA 是蚂蚁金服 自主研发 的 金融级 分布式中间件，包含了构建金融级云原生架构所需的各个组件，包括微服务研发框架，RPC 框架，服务注册中心，分布式定时任务，限流/熔断框架，动态配置推送，分布式链路追踪，Metrics监控度量，分布式高可用消息队列，分布式事务框架， 分布式数据库 代理层等组件，是一套分布式架构的完整的解决方案，也是在金融场景里锤炼出来的最佳实践。 蚂蚁金服期望通过逐步向社区开源 SOFA 中各个组件，来帮助更多机构和合作伙伴完成金融分布式转型，帮助大家更加快速构建稳定的金融级云原生的架构，也期望 SOFA 在蚂蚁体系之外的更大场景下去应用，来进一步锻造改进这套体系，使其更加完善和稳固，并具备更多金融级的属性。所以我们也非常欢迎社区的伙伴和各行业的伙伴能够参与共同探讨、交流和共建。 Why（为什么要做） SOFA 中间件在蚂蚁内部经历了十年的发展和四代架构的演进，被广泛应用在包括支付，借贷，信用，基金，保险等全金融场景， 支撑着蚂蚁平稳度过历次双十一，双十二，新春红包等大考，创造了25.6 w/s

前言 今天老顾带着大家了解一下 session会话在微服务架构中采用的技术方案 ，以及 企业应用中需要注意的问题。 session作用 我们知道在web应用中， web服务器和浏览器之间是用http协议进行通信的 ，而 http协议是无状态 的，也就是 每个请求都是独立 的。如：用户看一条A新闻，不管是谁看到的都是一模一样的新闻。也就是 跟用户是谁没有任何关系 。 但业务自身的发展，需要把 不同的内容展示给不同的用户 ，即 信息和用户状态关联 起来。如：历史阅读列表---列出用户之前看的新闻。这个需求就是跟用户相关， 每个用户看到的历史阅读列表都是不一样的。 Session的产生 就是为了解决这个问题，把 服务器和客户端之间进行状态保持 的解决方案。 session原理 浏览器在第一次访问web服务器， 服务器端会响应一个sessionId，并且把这个sessionId传输给浏览器，并以cookie保存sessionId到浏览器本地 。 以后的访问会 把这个cookie的sessionId以请求头的方式传给服务器 ，这样服务器就可以拿着 这个sessionId进行查找，服务器中有没有此sessionId对应的用户 ，这样就能标识出哪个用户，如果有用户相关的业务，就是 利用这个sessionId返回用户相关的业务 。 本质就是 浏览器客户端本地保存了sessionId ，

原文: Session分布式共享 = Session + Redis + Nginx 一、 Session 1、 Session 介绍 我相信，搞Web开发的对Session一定再熟悉不过了，所以我就简单的介绍一下。 Session:在计算机中，尤其是在网络应用中，称为“会话控制”。 每个用户（浏览器）首次与web服务器建立连接时，就会产生一个Session，同时服务器会分配一个SessionId给用户的浏览器。我们可以用Fiddler查看cookies中，会看到有一个ASP.Net_SessionId的cookie。大家都知道Http是无状态请求，但是ASP.Net中的Session仿佛又让Http请求变得有状态，其核心就在于这个叫ASP.Net_SessionId的cookie。大家可以想象一下，这个相当于数据库的Key，服务器那边再有个Session内容缓存表，是不是Session的内容就很容易得到了？当然Session不是那么简单，但Session原理不是本文介绍重点，所以请大家自行度娘。 2、又爱又恨的 Session 刚接触程序开发的人一定爱死Session了，因为Session让Http从无状态变成有状态了，页面之间传值、用户相关信息、一些不变的数据、甚至于查出来的DataTable也可以放进去，取值的时候只需要Session[Key]即可，真是方便极了

前言 消息队列 在互联网技术存储方面使用如此广泛，几乎所有的后端技术面试官都要在 消息队列 的使用和原理方面对小伙伴们进行360°的刁难。 作为一个在互联网公司面一次拿一次Offer的面霸，打败了无数竞争对手，每次都只能看到无数落寞的身影失望的离开，略感愧疚（ 请允许我使用一下夸张的修辞手法 ）。 于是在一个寂寞难耐的夜晚， 暖男 我痛定思痛，决定开始写 《吊打面试官》 系列，希望能帮助各位读者以后面试势如破竹，对面试官进行360°的反击，吊打问你的面试官，让一同面试的同僚瞠目结舌，疯狂收割大厂Offer！ 捞一下 上一期，简单的介绍了一下 消息队列 的基础知识，里面有消息队列的应用场景，以及使用之后可能带来的问题，但是上期没对怎么解决这些问题做回答，因为要控制篇幅嘛（明明是自己觉得MQ写不了多少期，要多怼一期出来！渣男） 咳咳，我们言归正传，没看的朋友去看一下，有助于这期的阅读： 《吊打面试官》系列-消息队列基础 面试开始 一个风度翩翩，穿着格子衬衣的中年男子，拿着一个满是划痕的mac向你走来，看着铮亮的头，心想着肯定是尼玛顶级架构师吧！但是我们看过暖男敖丙的系列，腹有诗书气自华，虚都不虚。 没错小伙子还是我，上次话说一半你就溜了，这次我非得好好的问问你。 好的面试官，因为上次着急，敖丙的系列更新了所以赶回家去看了！ 我信你个鬼，我们开始吧，上次说到了消息队列的消息重复消费

浅谈分布式一致性与CAP/BASE/ACID理论 https://www.cnblogs.com/zhang-qc/p/6783657.html 　　 ##转载请注明 　　CAP理论（98年秋提出，99年正式发表）： C（ Consistency）一致性： 在分布式系统中，数据一致更新，所有数据变动都是同步的； A（ Availability）可用性： 分布式系统中，部分节点故障，系统是否依然可响应客户端请求（对数据更新具备高可用性）； P（ Partition tolerance）分区容错性： 分区是相对于通信的时延要求来讲，指在时延要求内部分节点与其它节点联系不可达，在该情况下系统是否依然可用（可靠性）。该场景下不同于节点宕机情况，可能由于网络交换器故障，使形成不同分区，分区不可达，或者是当前延迟过大，超过了设定的值。 点对点的网络上，复杂的拓扑结构和独立的路由选择可能使连接具有非对称（asymmetric）、非传递的特性，使进程间不可以通信。 由于网络存在延迟和丢包等问题，P性质相对必须满足，所以常在C和A之间进行权衡。CAP理论说明系统的架构只能满足三点中的二点，无法设计出满足三点的完美的系统。可理解为：网络环境是不可靠的，因此会存在分区的发生，如果数据仅单点存储，那么其余分区的节点无法访问，因此分区无法容错。可以增加该数据项的备份，这样发生分区后各分区仍有该数据

“ 区块链 ，是互联网的二次革命。” “区块链，是互联网2.0。” “区块链，让我们从信息互联网跨越到价值互联网。” 这是从互联网发展的视角出发，对区块链有什么意义做出的一些回答。 谈起区块链的前景，人们会列举它能改变金融、能源、零售、文化、社交、游戏、物联网等，但我觉得，以上回答更为有力。 从 1994 年互联网开始商业化，经过近 25 年的发展，互联网已经彻底改变了我们周围的一切——经济、产业、生活。互联网从 1995 年左右的“信息高速公路”的说法，变成了无处不在的力量。现在，如果区块链是互联网 2.0，互联网曾经带来的改变以区块链的方式再来一次，随着区块链技术的进步和相关基础设施的完善，各种意想不到的应用会涌现出来。 信息传递 VS 价值转移 之前，互联网处理的是“信息”；现在，互联网可以处理“价值”。从 2008 年到 2018 年，酝酿了近十年的区块链技术弥补了互联网与数字世界中一直缺失的另一半。区块链提供了在数字世界中处理价值所需的两个基础功能：价值表示与价值转移，让互联网跃迁到价值互联网（见图1）。 图：信息互联网 VS 价值互联网 1990 年，万维网协议发明者蒂姆·伯纳斯-李写道：“一旦我们通过万维网连接信息，我们就可以通过它来发现事实、创立想法、买卖物品，以及创建新的关系，而这一切都是通过在过往时代不可想象的速度和规模来实现的。”到现在

摘自： https://www.cnblogs.com/powertoolsteam/p/redis.html Redis是什么？看这一篇就够了 本文由葡萄城技术团队编撰并首发 转载请注明出处： 葡萄城官网 ，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。 引言 在Web应用发展的初期，那时关系型数据库受到了较为广泛的关注和应用，原因是因为那时候Web站点基本上访问和并发不高、交互也较少。而在后来，随着访问量的提升，使用关系型数据库的Web站点多多少少都开始在性能上出现了一些瓶颈，而瓶颈的源头一般是在磁盘的I/O上。而随着互联网技术的进一步发展，各种类型的应用层出不穷，这导致在当今云计算、大数据盛行的时代，对性能有了更多的需求，主要体现在以下四个方面： 低延迟的读写速度：应用快速地反应能极大地提升用户的满意度 支撑海量的数据和流量：对于搜索这样大型应用而言，需要利用PB级别的数据和能应对百万级的流量 大规模集群的管理：系统管理员希望分布式应用能更简单的部署和管理 庞大运营成本的考量：IT部门希望在硬件成本、软件成本和人力成本能够有大幅度地降低 为了克服这一问题，NoSQL应运而生，它同时具备了高性能、可扩展性强、高可用等优点，受到广泛开发人员和仓库管理人员的青睐。 Redis是什么 Redis是现在最受欢迎的NoSQL数据库之一，Redis是一个使用ANSI