分布式开发

分布式锁是控制分布式系统或者不同系统之间共同访问共享资源的一种锁的实现，当不同主机共享了共享某一种资源时候往往通过互斥来除去彼此的干扰来保证一致性。 什么是分布式锁？分布式锁需要解决什么问题？ 互斥性 任意时刻只能有一个客户端获得锁 安全性 锁只能被持有该锁的客户端删除，不能被其他客户端删除 死锁 获得锁的客户端，出现意外宕机锁无法释放，资源也被永远锁住就出现了死锁 容错性 客户端出现宕机，可以是实现高可用 Redis实现分布式锁 1、首先使用get < key >检查被上分布式锁的key，返回nil表示没有上锁，返回string是锁的名字 2、使用setnx < key > < lockname >设置锁住的key和锁的名字，被锁住返回0反之返回1 设置锁之后，给锁设置一个过期时间也是必须的，也不能一直锁着手动去释放，所以我们就需要设置所的过期时间： 给上面的锁设置失效时间，失效时间为2s，2s后检查锁的状态 设置锁之后发现锁的状态有了明显的转变，实现的伪代码如下： 但是存在一个问题，使用setnx设置锁之后，设置失效时间之前就失效了那么就会一直处于被锁的状态，其他线程无法获得锁，简单来说就是 无法保证原子性。 Redis存在一种新的方法，将setnx和expire的功能结合在一起，开发出有过期时间的锁： SET key value [ EX seconds ] [ PX

转载自： http://dq.shejis.com/dqlw/201610/article_142755.html 国网电力科学研究院 张子仲 　　1 目标与架构 　　1.1 需求 　　随着信息系统应用的不断深入，加快构建全球能源互联网和全面建成“一强三优”现代公司的目标以及大数据、云计算等新技术的日趋成熟，同时在企业级数据资源管理应用方面也暴露出了不足。数据是信息化的核心，建设全业务统一数据中心是源端全业务融合、后端大数据分析的必然选择，对建设信息化企业具有重要意义。 图1 　　1.2 目标与原则 　　到“十三五”末，基本建成“数据干净透明、模型规范统一、分析灵活智能”的全业务统一数据中心，实现面向全业务范围、全数据类型、全时间维度数据的统一存储、管理与服务。 图2 　　全业务统一数据中心主要包括数据处理中心、数据分析中心和数据管理中心三部分 图3 　　①数据处理中心 　　数据处理中心为公司各业务应用提供逻辑统一的数据访问支撑，是原有业务系统各个分散数据库的归并、发展与提升，主要包括业务处理数据库与统一数据访问服务两个部分。 图4 　　(1)实现跨专业数据统一访问，促进跨部门的信息共享与业务数据融合; 　　(2)改变业务集成方式，消除数据复制，促进跨部门业务协同; 　　(3)隔离应用与数据库的直接连接，为统一数据模型的应用与数据管控提供技术支撑。 　　②数据分析中心 　

1、为什么要使用消息队列? 主要有三个原因: 解耦、异步、削峰 (1)解耦 传统模式: 传统模式的 缺点 ： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 中间件模式: 中间件模式的的 优点 ： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 (2)异步 传统模式: 传统模式的 缺点 ： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。 中间件模式: 中间件模式的的 优点 ： 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度 (3)削峰 传统模式 传统模式的 缺点 ： 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常 中间件模式: 中间件模式的的 优点 ： 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 2、使用了消息队列会有什么缺点? 分析 :一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。 要记住，不要给公司挖坑！ 回答 :回答也很容易，从以下两个个角度来答 系统可用性降低 :你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去

【编者按】DTCC 2019已经结束，云栖社区沉淀了很多阿里巴巴所分享的优质演讲 整理稿件 。这篇转载自IT168&ITPUB执行总编老鱼的公众号，分享给大家。 李飞飞，现任阿里巴巴集团副总裁、高级研究员，阿里云智能数据库事业部总负责人。加入阿里巴巴之前为美国犹他大学计算机系终身教授。研究成果多次获得了IEEE ICDE、ACM SIGMOD最佳论文奖等重要学术奖项。 2018年，李飞飞加入阿里巴巴达摩院，带领团队投入到具有自主知识产权的研究当中。目前，带领的阿里云智能数据库事业部所研发的新一代分布式数据库系统，支撑了阿里巴巴集团的复杂业务、海量数据和双11交易洪峰的挑战，已经被应用于多个城市的智能城市交通网络管理，并服务了金融、零售、物流、制造等行业企业。 2018年，阿里云数据库成功进入Gartner数据库魔力象限，这是该榜单首次出现中国公司，近日，阿里云数据库再次入选Forrester数据库评估报告，成为国内首个获得两大顶级机构认可的科技公司。 2019年5月10日，DTCC 2019(第十届中国数据库技术大会)在北京举办，李飞飞来到现场发表了精彩的主题演讲，并在大会期间接受了IT168&ITPUB执行总编老鱼的深度专访，众多独特观点精彩纷呈。 透露两条信息： 1、PolarDB从去年10月开始商业化到目前，已经成为阿里云上增长最快的数据库产品； 2

读累了就看看实操 https://www.cnblogs.com/huasky/p/10214642.html 一、SOA 概念：SOA：Service-Oriented Architecture，面向服务的架构，将应用程序的不同功能(服务)通过定义的接口来实现数据通信；服务治理；服务调度中心和治理中心； 架构演变：单一应用架构ORM | 垂直应用架构MVC | 分布式服务架构RPC | 流动计算架构SOA ORM ：流量小，单一应用，部署一起；关注于简化增删改查的对象关系映射， MVC ：流量增加，应用拆分；关注于提高前端开发速度； RPC ：远程过程调用；通过网络进行远程计算机服务的请求；核心业务抽取；关注于业务的复用和整合； 由统一到分布式： 使用场景由混乱到统一： SOA又叫服务治理，SOA就是帮助我们把服务之间调用的乱七八糟的关系给治理起来，然后提供一个统一的标准； 统一标准：各系统的协议、地址、交互方式。 新的交互方式：各个系统分别根据统一标准向数据总线进行注册，各子系统调用其他子系统时，我们并不关心如果找到其他子系统，我们只招数据总线，数据总线再根据统一标准找其他子系统，所以数据总线在这里充当一个只路人的作用。 数据总线是起到调度服务的作用，数据总线不是集成服务，数据总线更新一个调度框架，每个服务需要根据约定向数据总线注册服务；服务不是经过总线的

一、前言 　　运行环境window，redis版本3.2.1。此处暂不对Lua进行详细讲解，只从Redis的方面讲解。 二、Redis的Lua脚本 　　在Redis的2.6版本推出了脚本功能，允许开发者使用Lua语言编写脚本传到Redis中执行，在Lua脚本中也可以调用大部分的Redis命令。使用脚本有以下三个好处： 　　(1) 减少网络开销：有些时候需要多次请求Redis获取处理数据，而使用脚本功能就可以只使用一次请求完成相同操作，减少了网络往返时延。 　　(2) 原子操作：Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。也就是说在编写脚本的过程中无须担心会出现竞态条件，也就是无须使用事务。事务可以完成的所有功能，都可以用脚本来完成。 　　(3) 复用：客户端发送的脚本会永久存储在Redis中，这就意味着其他客户端(可以是其他语言开发的项目)可以复用这一脚本而不需要使用代码完成同样的逻辑。 三、Redis调用Lua 　　 1、EVAL命令 　　编写完脚本后最重要的就是在程序中执行脚本。Redis提供了EVAL命令可以使开发者像调用其他Redis内置命令一样调用脚本。EVAL的命令格式如下： 127.0.0.1:6379> eval script numkeys key [key ...] arg [arg ...] 　　script：脚本内容。numkeys

原文: 分布式事务,EventBus 解决方案:CAP【中文文档】 最新文档地址： https://github.com/dotnetcore/CAP/wiki 前言 很多同学想对CAP的机制以及用法等想有一个详细的了解，所以花了将近两周时间写了这份中文的CAP文档，对 CAP 还不知道的同学可以先看一下 这篇文章 。 本文档为 CAP 文献（Wiki），本文献同时提供中文和英文版本，英文版本目前还在翻译中，会放到Github Wiki 中。 目录 前言 1、Getting Started 1.1 介绍 1.2 应用场景 1.3 Quick Start 2、API接口 2.1 发布/发送 2.1.1 事务 2.2 订阅/消费 2.2.1 例外情况 3、配置 3.1 Cap Options 3.2 RabbitMQ Options 3.3 Kafka Options 3.4 SqlServer Options 3.5 MySql Options 4、设计原理 4.1 动机 4.2 持久化 4.3 通讯数据流 4.4 一致性 5、实现 5.1 消息表 5.2 消息格式 5.3 EventBus 5.4 重试 6、分布式事务 6.1 异步确保 7、FAQ 1、Getting Started 1.1 介绍 CAP 是一个遵循 .NET Standard 标准库的C#库

问题的起源 在电商等业务中，系统一般由多个独立的服务组成，如何解决分布式调用时候数据的一致性？ 具体业务场景如下，比如一个业务操作，如果同时调用服务 A、B、C，需要满足要么同时成功；要么同时失败。A、B、C 可能是多个不同部门开发、部署在不同服务器上的远程服务。 在分布式系统来说，如果不想牺牲一致性，CAP 理论告诉我们只能放弃可用性，这显然不能接受。为了便于讨论问题，先简单介绍下数据一致性的基础理论。 强一致 当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就保证能读到什么。根据 CAP 理论，这种实现需要牺牲可用性。 弱一致性 系统并不保证续进程或者线程的访问都会返回最新的更新过的值。系统在数据写入成功之后，不承诺立即可以读到最新写入的值，也不会具体的承诺多久之后可以读到。 最终一致性 弱一致性的特定形式。系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终一致性系统。 在工程实践上，为了保障系统的可用性，互联网系统大多将强一致性需求转换成最终一致性的需求，并通过系统执行幂等性的保证，保证数据的最终一致性。但在电商等场景中，对于数据一致性的解决方法和常见的互联网系统（如

随着大数据时代的到来，分布式是解决大数据问题的一个主要手段，随着越来越多的分布式的服务，如何在分布式的系统中对这些服务做协调变成了一个很棘手的问题。今天我们就来看看如何使用C# ，利用开源对分布式服务做协调。 在对分布式的应用做协调的时候，主要会碰到以下的应用场景： 业务发现（service discovery） 找到分布式系统中存在那些可用的服务和节点 名字服务 （name service） 通过给定的名字知道到对应的资源 配置管理 （configuration management） 如何在分布式的节点中共享配置文件，保证一致性。 故障发现和故障转移 （failure detection and failover） 当某一个节点出故障的时候，如何检测到并通知其它节点， 或者把想用的服务转移到其它的可用节点 领导选举（leader election） 如何在众多的节点中选举一个领导者，来协调所有的节点 分布式的锁 （distributed exclusive lock） 如何通过锁在分布式的服务中进行同步 消息和通知服务 （message queue and notification） 如何在分布式的服务中传递消息，以通知的形式对事件作出主动的响应 Consul Consul 是用Go开发的分布式服务协调管理的工具，它提供了服务发现，健康检查，Key／Value存储等功能

技术站点 Hacker News：非常棒的针对编程的链接聚合网站 Programming reddit：同上 MSDN：微软相关的官方技术集中地，主要是文档类 infoq：企业级应用，关注软件开发领域 OSChina：开源技术社区，开源方面做的不错哦 cnblogs，51cto，csdn：常见的技术社区，各有专长 stackoverflow：IT技术问答网站 GitHub：全球最大的源代码管理平台，很多知名开源项目都在上面，如Linux内核， OpenStack等免费的it电子书：http://it-ebooks.info/ DevStore:开发者服务商店 不错的书籍 人件 人月神话 代码大全2 计算机程序设计艺术 程序员的自我修养 程序员修炼之道 高效能程序员的修炼（成为一名杰出的程序员其实跟写代码没有太大关系） 深入理解计算机系统 软件随想录 算法导论（麻省理工学院出版社） 离线数学及其应用 设计模式 编程之美 黑客与画家 编程珠玑 C++ Prime Effective C++ TCP/IP详解 Unix 编程艺术 《精神分析引论》弗洛伊德 搞定：无压力工作的艺术 平台工具（都是开源的好东东哦） Redmine/Trac：项目管理平台 Jenkins/Jira(非开源)：持续集成系统（Apache Continuum，这个是Apache下的CI系统，还没来得及研究）