一起谈.NET技术,如何解决分布式系统中的跨时区问题[原理篇]

简介:   一、场景以及需求   为了让大家本文介绍的主题有一个比较直观的认识,我们给出一个具体的应用场景。一个跨国公司开发一套统一的办公系统,供遍布全球的所有分公司使用。客户端的UI采用Smart Client (Windows Forms应用),而主要的业务逻辑均通过WCF服务的形式提供。

  一、场景以及需求

   为了让大家本文介绍的主题有一个比较直观的认识,我们给出一个具体的应用场景。一个跨国公司开发一套统一的办公系统,供遍布全球的所有分公司使用。客户端的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

  关于这个分布式系统中跨时区问题的讨论暂时就到这里,在下篇中我将给出一个完整的例子,相信会使你对本文给出的解决方案有一个深刻的认识。

    [相关阅读]
目录
相关文章
|
8天前
|
机器学习/深度学习 存储 运维
分布式机器学习系统:设计原理、优化策略与实践经验
本文详细探讨了分布式机器学习系统的发展现状与挑战,重点分析了数据并行、模型并行等核心训练范式,以及参数服务器、优化器等关键组件的设计与实现。文章还深入讨论了混合精度训练、梯度累积、ZeRO优化器等高级特性,旨在提供一套全面的技术解决方案,以应对超大规模模型训练中的计算、存储及通信挑战。
32 4
|
21天前
|
传感器 人工智能 供应链
.NET开发技术在数字化时代的创新作用,从高效的开发环境、强大的性能表现、丰富的库和框架资源等方面揭示了其关键优势。
本文深入探讨了.NET开发技术在数字化时代的创新作用,从高效的开发环境、强大的性能表现、丰富的库和框架资源等方面揭示了其关键优势。通过企业级应用、Web应用及移动应用的创新案例,展示了.NET在各领域的广泛应用和巨大潜力。展望未来,.NET将与新兴技术深度融合,拓展跨平台开发,推动云原生应用发展,持续创新。
27 4
|
21天前
|
机器学习/深度学习 人工智能 Cloud Native
在数字化时代,.NET 技术凭借其跨平台兼容性、丰富的类库和工具集以及卓越的性能与效率,成为软件开发的重要平台
在数字化时代,.NET 技术凭借其跨平台兼容性、丰富的类库和工具集以及卓越的性能与效率,成为软件开发的重要平台。本文深入解析 .NET 的核心优势,探讨其在企业级应用、Web 开发及移动应用等领域的应用案例,并展望未来在人工智能、云原生等方面的发展趋势。
28 3
|
21天前
|
敏捷开发 缓存 中间件
.NET技术的高效开发模式,涵盖面向对象编程、良好架构设计及高效代码编写与管理三大关键要素
本文深入探讨了.NET技术的高效开发模式,涵盖面向对象编程、良好架构设计及高效代码编写与管理三大关键要素,并通过企业级应用和Web应用开发的实践案例,展示了如何在实际项目中应用这些模式,旨在为开发者提供有益的参考和指导。
21 3
|
21天前
|
开发框架 安全 Java
.NET技术的独特魅力与优势,涵盖高效的开发体验、强大的性能表现、高度的可扩展性及丰富的生态系统等方面,展示了其在软件开发领域的核心竞争力
本文深入探讨了.NET技术的独特魅力与优势,涵盖高效的开发体验、强大的性能表现、高度的可扩展性及丰富的生态系统等方面,展示了其在软件开发领域的核心竞争力。.NET不仅支持跨平台开发,具备出色的安全性和稳定性,还能与多种技术无缝集成,为企业级应用提供全面支持。
27 3
|
14天前
|
供应链 算法 安全
深度解析区块链技术的分布式共识机制
深度解析区块链技术的分布式共识机制
28 0
|
2月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
4月前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
126 2
基于Redis的高可用分布式锁——RedLock
|
12天前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
26 8
|
28天前
|
NoSQL Redis
Redis分布式锁如何实现 ?
Redis分布式锁通过SETNX指令实现,确保仅在键不存在时设置值。此机制用于控制多个线程对共享资源的访问,避免并发冲突。然而,实际应用中需解决死锁、锁超时、归一化、可重入及阻塞等问题,以确保系统的稳定性和可靠性。解决方案包括设置锁超时、引入Watch Dog机制、使用ThreadLocal绑定加解锁操作、实现计数器支持可重入锁以及采用自旋锁思想处理阻塞请求。
54 16