【福尔摩斯探案集】数据库和应用程序时间出现14小时时差之迷

疑云初现

  "1983年小巷,12月晴朗,夜的第七章,打字机继续推向,接近事实的那下一行"
  耳边传来动听的音乐声,双眼微眯,本·福尔摩斯正沉浸在音乐描绘的场景中,忽然耳边响起一阵叮铃叮铃的清脆响声,原来是电话响了,本·福尔摩斯立马回过神来,"看来是案子上门了",本·福尔摩斯心想,然后接起电话,电话的那头,急切的声音传来:
  "喂,请问是本·福尔摩斯探长吗?我们这里发生了一件奇怪的案子,需要您来查探一下"。
  挂断电话,本·福尔摩斯火速赶往现场。抵达现场后,联系福尔摩斯的小兄弟立马汇报了情况,"探长,我们这里出现了一件奇怪的案子,是这样的,我们有两个应用,使用的都是同一个数据库,查同样的表的同样的字段,但是两个应用的接口返回的结果截然不同,其中一个接口返回的是正确的时间戳,另一个接口返回的是错误的时间戳,并且两个时间戳时差为14小时"
  本·福尔摩斯捋了一捋,"哦?这么奇怪?我来看一看呢",然后福尔摩斯开始还原现场。首先查看了数据库:
file
  然后查看了正确的返回:
file
  换算成时间是:
file
  和数据库相符,再来看一下错误的返回:
file
  换算成时间是:
file
  可以看到两者之间的确差了14个小时,并且是错误的数据比正确的数据要晚14个小时。此时本·福尔摩斯陷入了深深的沉思...

疑云丛丛

  深深的吸了一口气,本·福尔摩斯在脑海中列出了自己的疑问:
  1."为什么两者查的是同一个库同一张表甚至同一个字段,结果会不一样呢?"
  2."就算不一样,那为何不是差12小时,13小时,15小时,偏偏是14小时呢?"
   本·福尔摩斯百思不得其解,他一步一步的脑海中重复这个过程,"到底是哪里不一样呢?肯定是有哪里不一样!",忽然本·福尔摩斯灵光一闪,想到这两者的共同点都是接收了Mybatis服务员提供的服务,而只有Mybatis在服务过程中会接触到这个字段,并且将其转换,"难道是Mybatis动了手脚?那为什么之前都没问题呢?",本·福尔摩斯很快否定了Mybatis动了手脚,但是除了Mybatis,也没有其他人可以动手脚了啊?一时间,案子陷入了层层迷雾中,毫无进展。
  "看来还是得从Mybatis入手,他肯定隐瞒了一些我们不知道的事",心里如是想,于是本·福尔摩斯找到了Mybatis,打算和Mybatis深入谈谈,但是Mybatis对本·福尔摩斯的疑问矢口否认,Mybatis脾气暴躁的说:"我说了我没有做任何手脚!我没有!",一时间,本·福尔摩斯和Mybatis陷入了一种无言的氛围,忽然,Mybatis说:"咦,对了,我其实一直都比较懒,对createTime的查询这些我都委托给JDBC去处理了,处理完了我只是负责把对应的值转换为对应的类型,会不会是JDBC对createTime动了手脚?"。
  本·福尔摩斯精光一闪,"你为什么不早说呢?",然后匆匆跑去查看监控,在命名为DefaultResultSetHandler的监控里,终于在快进到getPropertyMappingValue时验证了Mybatis的说法: file
  再跟随监控进入DateTypeHandler查看:
file
  看到这里,本·福尔摩斯自信一笑,他感觉正在接近事实的真相:
file
  "原来是它,ResultSet!",没错,它就是当初本·福尔摩斯和JDBC大战时,经常会遇到的对手, 大名鼎鼎的ResultSet结果集,"那它又是怎样神不知鬼不觉的把数据替换掉的呢?"本·福尔摩斯继续查看。

真相大白

  跟着监控层层深入,本·福尔摩斯来到了犯案的第一现场:
file
  本·福尔摩斯注意到,这里有一个stringConverter,包含一个ValueFactory属性:
file
  而这个targetVf的具体类型为YearToDateValueFactory:
file
  YearToDateValueFactory也有一个targetVf,其具体的实例类型为:
file
  然后会调用其createFromTimestamp方法:
file
  这里放大监控看一下:
file
  原来如此,原来真的是JDBC做了手脚,把时间改了,我们从数据库正确获取到了时间是 2021-02-22 11:48:04,但是JDBC调用了calendar.getTimeInMills()方法,在该方法中把时间改成了 2021-02-23 11:48:04,正好差了14个小时,再继续查看监控:
file
  原来这里,isTimeSet标志位为false,所以要更新时间,至于这个更新时间的过程,比较复杂,本·福尔摩斯为了照顾各位看官的感受,直接讲原因,首先来看SqlTimestampValueFactory的构造方法:
file
  初始化时,calendar为null,会根据传入的TimeZone去初始化一个Calendar,此时TimeZone为CST,Locale为US,直接说,这里的TimeZone是Mybatis从数据库的默认时区获取的,我们使用Mysql:
file
  很好理解,Mysql使用的时区是随系统时区,而对应的系统时区为CST,因此Mysql默认会使用CST时区,这就是为什么SqlTimestampValueFactory构造方法中传入的TimeZone为CST,而CST时区又是一个神奇的时区:

美国中部时间:Central Standard Time (USA) UT-6:00
澳大利亚中部时间:Central Standard Time (Australia) UT+9:30
中国标准时间:China Standard Time UT+8:00
古巴标准时间:Cuba Standard Time UT-4:00

  可以看到,CST能表示4个时区,而JDK8源码中默认设置的Locale为US,则代表SqlTimestampValueFactory中的Calendar代表的时间为美国中部西六区的时间,而在SqlTimestampValueFactory.createFromTimestamp方法中调用了该calendar实例getTimeInMillis方法:
file
  而该方法调用updateTime(),又调用computeTime()方法,其中有这么一行代码:
file
  computeTime方法的整个逻辑就是,获取程序运行的机器的默认时区(一般我们都是东八区Asia/Shanghai),然后根据该时区,更新之前的calendar代表的时间,而根据之前的分析我们知道,此时的calendar代表的时区是美国中部时间西六区,而现在需要更新为中国标准时间,以英国格林威治时间为标准0时,美国西六区-6,而中国处于东八区+8,因此两个时间差为14小时,并且是程序得到的时间晚于数据库时间14小时。
  "那为什么另外一个程序却没有问题呢?"此时,报案的小兄弟提出了一个疑问
  "很简单,因为这两个程序使用的mysql-connector-java的版本不同"
file
file
  早期版本(版本号为mysql-connector-java:5.x及以前)的代码实现中获取的calendar默认就是系统当前时区,不存在不同的情况,自然不会影响最后的结果:
file
file
  如果是mysql-connector-java:6.x 及以上的版本,则会出现这种时差问题,另外mysql-connector-java:5.x 和mysql-connector-java:6.x的一个显著区别是,配置的数据库的driverName不同:

driverClassName: com.mysql.jdbc.Driver # mysql-connector-java 5.x及之前版本中的
driverClassName: com.mysql.cj.jdbc.Driver # mysql-connector-java 6.x及后续版本中的

华丽谢幕

  "不愧是本·福尔摩斯探长,手到擒来,那我们下次再遇到这种情况应该如何解决呢?"
  "很简单,既然我们知道了差14小时的原因,我们就能对症下药了,具体根据实际情况选择"
  1.修改程序的数据库连接串,指定时区:
  > &serverTimezone=GMT%2B8
  2.修改数据库的时区,使数据库时区和程序运营时的默认时区相同:
  > set time_zone = '+8:00';

  "如果邪恶 是华丽残酷的乐章 它的终场 我会 亲手写上"
  "晨曦的光 风干最后一行忧伤 黑色的墨 染上安详"
  伴随着音乐,福尔摩斯悠悠睡去,静待下一桩案件的到来....

本文由博客一文多发平台 OpenWrite 发布!

已标记关键词 清除标记
相关推荐
DirectX修复工具(DirectX Repair)是一款系统级工具软件,简便易用。本程序为绿色版,无需安装,可直接运行。 本程序的主要功能是检测当前系统的DirectX状态,如果发现异常则进行修复。程序主要针对0xc000007b问题设计,可以完美修复该问题。本程序中包含了最新版的DirectX redist(Jun2010),并且全部DX文件都有Microsoft的数字签名,安全放心。 本程序为了应对一般电脑用户的使用,采用了易用的一键式设计,只要点击主界面上的“检测并修复”按钮,程序就会自动完成校验、检测、下载、修复以及注册的全部功能,无需用户的介入,大大降低了使用难度。在常规修复过程中,程序还会自动检测DirectX加速状态,在异常时给予用户相应提示。 本程序适用于多个操作系统,如Windows XP(需先安装.NET 2.0,详情请参阅“致Windows XP用户.txt”文件)、Windows Vista、Windows 7、Windows 8、Windows 8.1、Windows 8.1 Update、Windows 10,同时兼容32位操作系统和64位操作系统。本程序会根据系统的不同,自动调整任务模式,无需用户进行设置。 本程序的V4.0版分为标准版、增强版以及在线修复版。所有版本都支持修复DirectX的功能,而增强版则额外支持修复c++的功能。在线修复版功能与标准版相同,但其所需的数据包需要在修复时自动下载。各个版本之间,主程序完全相同,只是其配套使用的数据包不同。因此,标准版和在线修复版可以通过补全扩展包的形式成为增强版。本程序自V3.5版起,自带扩展功能。只要在主界面的“工具”菜单下打开“选项”对话框,找到“扩展”标签,点击其中的“开始扩展”按钮即可。扩展过程需要Internet连接,扩展成功后新的数据包可自动生效。扩展用时根据网络速度不同而不同,最快仅需数秒,最慢需要数分钟,烦请耐心等待。如扩展失败,可点击“扩展”界面左上角小锁图标切换为加密连接,即可很大程度上避免因防火墙或其他原因导致的连接失败。 本程序自V2.0版起采用全新的底层程序架构,使用了异步多线程编程技术,使得检测、下载、修复单独进行,互不干扰,快速如飞。新程序更改了自我校验方式,因此使用新版本的程序时不会再出现自我校验失败的错误;但并非取消自我校验,因此程序安全性与之前版本相同,并未降低。 程序有更新系统c++功能。由于绝大多数软件运行时需要c++的支持,并且c++的异常也会导致0xc000007b错误,因此程序在检测修复的同时,也会根据需要更新系统中的c++组件。自V3.2版本开始使用了全新的c++扩展包,可以大幅提高工业软件修复成功的概率。修复c++的功能仅限于增强版,标准版及在线修复版在系统c++异常时(非丢失时)会提示用户使用增强版进行修复。除常规修复外,新版程序还支持C++强力修复功能。当常规修复无效时,可以到本程序的选项界面内开启强力修复功能,可大幅提高修复成功率。请注意,请仅在常规修复无效时再使用此功能。 程序有两种窗口样式。正常模式即默认样式,适合绝大多数用户使用。另有一种简约模式,此时窗口将只显示最基本的内容,修复会自动进行,修复完成10秒钟后会自动退出。该窗口样式可以使修复工作变得更加简单快速,同时方便其他软件、游戏将本程序内嵌,即可进行无需人工参与的快速修复。开启简约模式的方法是:打开程序所在目录下的“Settings.ini”文件(如果没有可以自己创建),将其中的“FormStyle”一项的值改为“Simple”并保存即可。 新版程序支持命令行运行模式。在命令行中调用本程序,可以在路径后直接添加命令进行相应的设置。常见的命令有7类,分别是设置语言的命令、设置窗口模式的命令,设置安全级别的命令、开启强力修复的命令、设置c++修复模式的命令、控制Direct加速的命令、显示版权信息的命令。具体命令名称可以通过“/help”或“/?”进行查询。 程序有高级筛选功能,开启该功能后用户可以自主选择要修复的文件,避免了其他不必要的修复工作。同时,也支持通过文件进行辅助筛选,只要在程序目录下建立“Filter.dat”文件,其中的每一行写一个需要修复文件的序号即可。该功能仅针对高级用户使用,并且必须在正常窗口模式下才有效(简约模式时无效)。 本程序有自动记录日志功能,可以记录每一次检测修复结果,方便在出现问题时,及时分析和查找原因,以便找到解决办法。 程序的“选项”对话框中包含了7项高级功能。点击"常规”选项卡可以调整程序的基本运行情况,包括日志记录、安全级别控制、调试模式开启等。只有开启调试模式后才能在C
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页