分布式系统中

❶ 如何解决分布式系统中的跨时区问题

从跨时区的角度对DateTime这个我们熟颂唯知的类型进行了深入探讨，它们都是为这篇文章作的准备工作。在接下来的两篇文章中，我们将完整的介绍如果在一个分布式系统中处理时区的问题。
一、场景以及需求
为了让大家本文介绍的主题有一个比较直观的认识，我们给出一个具体的应用场景。一个跨国公司开发一套统一的办公系统，供遍布全球的所有分公司使用。客户端的UI采用Smart Client （Windows Forms应用），而主要的业务逻辑均通过WCF服务的形式提供。我们将承载业务服务的服务器成为应用服务器，应用服务器部属于中国境内（东8区）。主要的客户端（分公司）分布于三个主要的国家和地区：北美、欧州和澳洲。
不论客户端和服务器之间，还是不同的客户端之间所处的时区均不相同，在进行时间处理的时候就会遇到一些麻烦：某个客户端通过服务调用获取的时间值应该基于哪个时区？对于这个问题，不同的场景可能有不同的要求。在大部分情况下，我们希望获取的时间值就是基于客户端的本地时区。不过也有些场景我们希望获取的时间值对应的时区是描述对象基于的那个时区。比如说，美国分公司于当地时间9月1号早8点举行开业典礼，欧洲分公司员工读取这条信息就没有必要将时间转换成基于本地时区的时间。
不过，本文不考虑这种情况，我们的最终要求是：客户端应用根本不用考虑时区问题，就像是一个单纯的本地应用一样。客户端调用服务传入的时间是DateTimeKind.Local时间或者DateTimeKind.Unspecified时间，同理通过服务调用返回的时间也应该是基于客户端所在时区的时间。
二、解决方案实现原理
现在我们就来谈谈如何解决上面提出的问题。既然时区的处理不能在客户端做，换言之就必须在服务端实现。我们的一个前提是：在数据库中不存储时区的任何信息。在这样一个前提下实现上述的目标，野悔培需要解决两个问题：时间的保存和时间获取。
在时间的保存方面，既然数据库中能保存任何时区偏移之类的信息。在这种情况下，我们必须让所有保存在数据库中的时间都是基于同一个时区。我们可以选择应用服务器所在的时区，也可以直接采用UTC时间。我们的方案采用后者，即数据库所有时间保存为UTC时间 。
时间在数据库中的存储形式确定了，现在又出现一个问题：客户端传来的时间为客户端所在时区的当地时间，服务端接收到客户端发送的时间后，需要基于客户端相应时区转换成UTC时间才能保存到数据库。那么，服务端如何获取客户端所在的时区信息呢？将其作为服务操作的参数肯定是不可取的。
如果你看过我之前的WCF系列文章，可能会记前游得我有一篇介绍如何通过WCF扩展实现在客户端和服务端之间传递上下文的文章：《通过WCF Extension实现Context信息的传递》。在这篇文章中我通过WCF扩展实现了将可户端的Culture和UICulture自动传向了服务端，从而确保两边保存一样的语言文化环境上下文。如果我们能够将基于客户端本地的TimeZoneInfo作为上下文进行传递，就能解决服务端对客户端的时区识别问题了。
关于保存时间的处理大体可以通过上面的序列图（点击看大图）来描述。客户端将基于本地时区的DateTimeKind.Local或者DateTimeKind.Unspecified时间作为输入操作调用某个服务，与此同时，本地的TimeZoneInfo序列化后作为上下文传递到服务端。服务端接将接收到的时间，根据接收到TimeZoneInfo上下文转换成DateTimeKind.Utc时间，并保存到数据库中。
当客户端调用服务获取某个时间的时候，本地的同样作为上下文信息被传递到服务端。借助于这个TimeZoneInfo，服务端可以将数据库中以UTC形式保存的时间转换成基于客户端时区的DateTimeKind.Local时间。右图（点击看大图）所示的序列图反映了这个过程。
三、TimeZoneInfo的序列化问题
在《谈谈你最熟悉的System.DateTime[上篇]》对TimeZoneInfo这个类进行介绍中，我说该类是可以被序列化的，序列化对于解决跨时区问题很重要。就是因为我们需要将TimeZoneInfo作为上下文在客户端和服务端进行传递，换言之，就是将TimeZoneInfo对象进行序列化，将序列化后的内容放入出栈消息（Outgoing Message）的消息报头（Message Header）中。
不过关于TimeZoneInfo对象序列化，我们一般并不会真正地将整个TimeZoneInfo对象交给序列化器去做序列化，而是利用定义在TimeZoneInfo中的两个特殊的方法来进行序列化和反序列化的工作。一个是实例方法ToSerializedString，将TimeZoneInfo转换成序列化后的一个字符串；另一个则静态方法FromSerializedString，对序列化后的字符转进行反序列化生成TimeZoneInfo对象。这两个方法的定义如下：
1: [Serializable]
2: public sealed class TimeZoneInfo
3: {
4: //Others
5: public static TimeZoneInfo FromSerializedString(string source);
6: public string ToSerializedString();
7: }

下面的代码演示了通过上述的这两个方法对TimeZoneInfo的序列化和反序列化的实现：
1: string serializedString = TimeZoneInfo.Local.ToSerializedString();
2: Console.WriteLine("SerializedString: {0}\n", serializedString);
3: TimeZoneInfo deserializedTimeZone = TimeZoneInfo.FromSerializedString(serializedString);
4: Console.WriteLine("deserializedTimeZone.Equals(TimeZoneInfo.Local) ? {0}", deserializedTimeZone.Equals(TimeZoneInfo.Local));
5: Console.WriteLine("deserializedTimeZone == TimeZoneInfo.Local ? {0}", deserializedTimeZone == TimeZoneInfo.Local);

下面是输出结果，从中我们看出最终被序列化后的文本的内容。此外，输出结果也反映两个另一个信息：两个包含时区信息的TimeZoneInfo对象，调用Equals方法和使用==操作符得到不一样的结果。个人觉得这是微软作得不太到位的地方。
1: SerializedString: China Standard Time;480;(UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi;China Standard Time;China Daylight Time;;
2:
3: deserializedTimeZone.Equals(TimeZoneInfo.Local) ? True
4: deserializedTimeZone == TimeZoneInfo.Local ? False
关于这个分布式系统中跨时区问题的讨论暂时就到这里，在下篇中我将给出一个完整的例子，相信会使你对本文给出的解决方案有一个深刻的认识。转载，仅供参考。

❷ 分布式系统的基础设施 是什么

一个大型、稳健、成熟的分布式系统的背后，往往会涉及众多的支撑系统，我们将这些支撑系统称为分布式系统的基础设施。昌裤高除了前面所介绍的分布式协作及配置管理系统ZooKeeper,我们进行系统架构设计所依赖的基础设施，还包括分布式缓存系统、持久化存储、分布式消息系统、搜索引擎，以及CDN系统、负载均衡系统、运维自动化系统等，还有后面章节所要介绍的实时计算系统、离线计算系统、分布式文件系统、日志收集系统、监控系统、数据仓库等。
分布式缓存主要用于在高并发环境下，减轻数据库的压力，提高系统的响应速度和并发吞吐。当大量的读、写请求涌向数据库时，磁盘的处理速度与内存显然不在一个量级，因此，在数据库之前加一层缓存，能够显著提高系统的响应速度，并降低数据库的压力。作为传统的关系型数据库，MySQL提供完整的ACID操作，支持丰富的数据类型、强大的关联查询、where语句等，能够非常客易地建立查询索引，执行复杂的内连接、外连接、求和、排序、分组等操作，并且支持存储过程、函数等功能，产品成熟度高，功能强大。但是，对于需要应对高并发访问并且存储海量数据的场景来说，出于对性能的考虑，不得不放弃很多传统关系型数据库原本强大的功能，牺牲了系统的易用性，并且使得系统的设计和管理变得更为复杂。这也使得在过去几年中，流行着另一种新的存储解决方案——NoSQL，它与传统的关系型数据库最大的差别在于，它不使用SQL作为查询语言来查找数据，而采用key-value形式进行查找，提供了更高的查询效率及吞吐，并且能够更加方便地进行扩展，存储海量数据，在数千个节点上进行分区，自动进行数据的复制和备份。在分布式系统中，消息作为应用间通信的一种方式，得到了十分广泛的应用。消息可以被保存在队列中，直到被接收者纯码取出，由于消息发送者不需要同步等待消息接收者的响应，消息的异步接收降低了系统集成的耦合度，提升了分布式系统协作的效率，使得系统能够更快地响应用户，提供更高的吞吐。
当系统处于峰值压力时，分布式消息队列还能够作为缓冲，削峰填谷，缓解集群的压力，避免整个系统被压垮。垂直化的搜索引擎在分布式系统中是一个非常重要的角耐尺色，它既能够满足用户对于全文检索、模糊匹配的需求，解决数据库like查询效率低下的问题，又能够解决分布式环境下，由于采用分库分表，或者使用NoSQL数据库，导致无法进行多表关联或者进行复杂查询的问题。

❸ 分布式系统特点有哪些

分布式系统特点：

1、分布性。分布式系统由多台计算机组成，它们在地域上是分散的，可以散布在一个单位、一个城市、一个国家，甚至全球范围内。整个系统的功能是分散在各个节点上实现的，因而分布式系统具有数据处理的分布性。

2、自治性。分布式系统中的各个节点都包含自己的处理机和内存，各自具有独立的处理数据的功能。通常，彼此在地位上是平等的，无主次之分，既能自治地进行工作，又能利用共享的通信线路来传送信息，协调任务处理。

3、并行性。一个大的任务可以划分为若干个子任务，分别在不同的主机上执行。

4、全局性。分布式系统中必须存在一个单一的、全局的进程通信机制，使得任何一个进程都能与其他进程通信，并且不区分本地通信与远程通信。同时，还应当有全局的保护机制。系统中所有机器上有统一的系统调用集合，它们必须适应分布式的环境。在所有CPU上运行同样的内核，使协调工作更加容易。

5、分布式系统更加的开放，具有相同的接口规范使得集群计算机能够方便的进行数据操作，系统协同度更高；

对外：体现在统一的接口描述上，用统一的接口描述语言描述一套所有服务器都知道的规则，这样各服务器的交互问题上没什么问题了。具体的接口实现根据各个服务器的情况具体实现，从而把实现和声明进行了有效的解耦。对内：各台服务器内部的策略和实现也需要解耦，以免整个服务器是按照实现和声明逻辑实现的，但是服务器内部确实一个整体的，对于分布式的开放性将会大打折扣。

❹ 什么是分布式系统中的幂等性

幂等性 ：就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

接口幂等性不只是分布式事务方便回滚的保证，同时也是SOA服务实现中摒歼棚行除重复消息的保证。

那就是支付，用户购买商品使用约支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条。

方法一、 单次支付请求，也就是直接支付了，不需要额外的数据库操作了，这个时候发起异步请求创建一个唯一的ticketId，就是门票，这张门票只能使用一次就作废，具体步骤如下：

如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样的

方法二、 分布式环境下各个服务相互调用

这边就要举例我们氏哗的系统了，我们支付的时候先要扣款，然后更新订单，这个地方就涉及到了订单服务以及支付服务了。

用户调用支付，扣款成功后，更新对应订单状态，然后再保存流水。

而在这个地方就没必要使用门票ticketId了，因为会比较闲的麻烦

（支付状态：未支付，已支付）

步骤：

1、查询订单支付状态

2、如果已经支付，直接返回结果

3、如果未支付，则支付扣款并且保存流水

4、返回支付结果

如果步骤4通信失败，用户再次发起请求，那么最终结果还是一样的

对于做过支付的朋友，幂等，也可以称之为冲正，保证客户端与服和拿务端的交易一致性，避免多次扣款。

❺ 什么是分布式系统

分布来式系统是一个硬件源或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。

正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。

(5)分布式系统中扩展阅读

分布式系统系统优点

1、经济：微处理机提供了比大型主机更好的性能价格比

2、速度：分布式系统总的计算能力比单个大型主机更强

3、固有的分布性：一些应用涉及到空间上分散的机器

4、可靠性：如果一个机器崩溃,整个系统还可以运转

5、渐增：计算能力可以逐渐有所增加

❻ 分布式系统中常见技术解决的问题是什么

分布式系统是一个非常广泛的概念，它最终要落实到解纯厅决实际问题上，不同的问题有不同的方法和架构。所有的开源软件都是以某个应用场景出现，而纯粹以“分布式”概念进行划分的比较少见。举个栗子！飔拓AInspir就是构建于分布式系统之上，它的特点在于大数据支持，基于Hadoop和Spark技术，支持海量数据挖掘；深度学习支持，支持运行于GPU之上的深度学习算法，大幅提扒裤陪高预测准确度和降低误差率；多数据源支持，支持RDBMS、NoSQL、消息队列和文本数据源；支持私有云和公有云部署；MaaS(Model as a Service)支持，模型云端共享，降低建模成本，支持数据的集成接入；业务模型，建立行业模型，让客户更关春蠢注于业务；算法组件化，提供数据源、数据预处理、特征工程、统计分析、机器学习、文本处理六大类型的数据挖掘组件；GUI模型编排，采用Drag and Drop体验式建模过程；

❼ 如何理解分布式系统中的机制与策略

近年来由于计算机网络的快速成长,策略性分布式系统变得越来越重要。在传统基于分布式系统研究中,代理都被假设为服从性的。这种假设忽略了不同代理之间的利益关系,也即当从属于不同组织的代理的行为遵循个体利益最大化的策略而非全局算法时,系统的动因(Incentive)就成为了一个急待解决的重要问题。机制设计(Mechanism Design)从经济学和博弈论中得到的概念能够描述策略性的代理,提供代理的动因,能解决这样的问题,从而达到个体自私的代理的利润最大化的同时,全局系统的最优化。 然而,在传统的机制设计问题定义中,人们考虑的通常只有用户愿意支付的价格或者服务商的成本,而不同用户,不同服务商之间的差异性被忽视了。在实际情况中,不同用户视同一服务商,基于不同用户考量的标准和参数不同,对该服务的估值是不一样的。相应的,不同服务商根据具体的情况,服务同一用户的服务成本很有可能也是不同的。在这样的前提下,基于传统的VCG的机制将不能保证strategyproof的特性,我们将提出Value-based解决方案来替代。 同时,在理性前提假设下,不同场景中的机制是不一样的。在本文中,我们讲分别讨论相应场景下的strategyproof机制。我们还将结合实际的分布式策略系统的说明机制的适用性,其中包括了从最早web cache,分布式存储,计算,到p2p文件共享,adhoc网络以及最近很热门的认知无线电网络,证明了我们的机制可以很好的解决系统中存在的动因问题,让博弈方说出真实的类型值,做出理性的判断。 另外,我们也将引入双向拍卖的概念来讨论最复杂的多服务对多用户的场景。我们从双向拍卖的背景开始,逐一介绍双向拍卖的运行环境和相应的买家卖家报价策略,并在McAfee的机制基础上提出我们的双向VCG机制,并证明了在一定条件下的strategyproof特性。最后,我们也以实际的外汇交易系统中的定价策略为例,讨论了双向拍卖中第三方撮合交易的方法以及原理。

❽ 什么是分布式系统

分布式系统是建立在网络上的软件系统。 处理协助任务，然后整合结果。在分布式系统中，一组独立的计算机向用户呈现一个统一的整体，就像一个系统一样。系统具有多种通用的物理和逻辑资源，可以动态分配任务，分散的物理和逻辑资源可以通过计算机网络实现信息交换。系统中有一个分布式操作系统，以全局方式管理计算机资源。通常，对于用户来说，分布式系统只有一个模型或范例。在操作系统之上，一个软件中间件层负责实现这个模型。分布式系统的一个著名例子是万维网，在渗亮万维网中，一切看起来都像一个文档(网页)。在计算机网络中，这种统一性、模型和软件是不存在的。用户看到的是实际察喊尘的机器，计算机网络并没有让这些机器看起来千篇一律。如果这些机器有不同的硬件或不同的操作系统，那么这些差异对用户来说是完全可见的。如果用户想要在远程机器上运行程序，他必须登录到远程机器上并在该机器上运行程序。分布式系统和计算机网络系统的共同点是大部分分布式系统都是建立在计算机网络上的，所以分布式系统和计算机网络的物理结构基本相同。两者的区别在于分布式操作系统和网络操作系统的设计思想不同，这就决定了它们在结构、工作方式和功能上也是不同的。网络操作系统要求网络用户在使用网络资源时首先了解网络资源。网络用户必须了解网络中每台计算机的功能和配置、软件资源和网络文件结构。如果用户想要读取网络中的共享文件，他们必须知道该文件放在哪个计算机和目录中。分布式操作系统以全局方式管理系统资源，可以随意为用户调度网络资源，调度过程“透明”。当用户提交作业时，分布式操作系统可以根据需要选择系统中最合适的处理器，将用户的作业提交给处理程序，在处理程序完成作业后将结果传递给用户。在这个过程中，用户并没有意识到多败禅个处理器的存在，系统就像一个处理器。