首页 > 编程技术 > html

同一个文件在windows和linux下计算md5哈希不一致的原因及解决方法

发布时间:2017-7-6 23:23

本文介绍了同一个文件在windows和linux下计算md5哈希不一致的原因及解决方法,非常实用,有兴趣的同学可以参考一下本文

最近项目需要,需要对客户传过来的文件进行MD5校验,在实现的过程中前前后后遇到了若干问题,在这里总结一下。

md5的计算采用openssl实现,具体代码网上很多,这里不再赘述。需要注意的问题

1 读取文件内容时,文件打开方式要用二进制方式(rb),因为用户文件有可能是linux格式,如果用文本方式打开,可能会改变原始的内容,造成计算不准。

2 结果检验。windows可以随便下载一个md5计算工具,网上很多,我用的是HashMyFiles。linux下面,md5sum 文件名 即可。

还有一个隐藏得问题需要注意,我们在这里好一阵郁闷。

程序编写完毕,再windows测试都通过了,把文件上传到linux,再运行程序,居然算出来的md5哈希和windows不一样。

经过一阵跟踪、断点、打印发现,文件上传到linux后,大小居然发生了变化,原来问题出在ftp,ftp上传得过程中采用了文本模式,会把文件中换行回车替换为换行。于是重新用二进制模式上传,计算结果一致,问题解决。

总结一下:文件打开读取要用二进制方式,文件传输也要用二进制方式。

本文介绍了查看import的类是出自哪个jar包的方法,非常实用,有兴趣的同学可以参考一下

 

 代码如下复制代码

publicstaticvoidmain(String[] args) {       

        ProtectionDomain pd = StringUtils.class.getProtectionDomain();

        CodeSource cs = pd.getCodeSource();

        System.out.println(cs.getLocation());

    }

 

打印出:file:/D:/work_ser_demo/springtest/WebContent/WEB-INF/lib/commons-lang-2.4.jar

本文主要介绍了如何设计一个秒杀系统的相关知识。具有很好的参考价值。下面跟着小编一起来看下吧

什么是秒杀

秒杀场景一般会在电商网站举行一些活动或者节假日在12306网站上抢票时遇到。对于电商网站中一些稀缺或者特价商品,电商网站一般会在约定时间点对其进行限量销售,因为这些商品的特殊性,会吸引大量用户前来抢购,并且会在约定的时间点同时在秒杀页面进行抢购。

秒杀系统场景特点

秒杀架构设计理念

限流: 鉴于只有少部分用户能够秒杀成功,所以要限制大部分流量,只允许少部分流量进入服务后端。

削峰:对于秒杀系统瞬时会有大量用户涌入,所以在抢购一开始会有很高的瞬间峰值。高峰值流量是压垮系统很重要的原因,所以如何把瞬间的高流量变成一段时间平稳的流量也是设计秒杀系统很重要的思路。实现削峰的常用的方法有利用缓存和消息中间件等技术。

异步处理:秒杀系统是一个高并发系统,采用异步处理模式可以极大地提高系统并发量,其实异步处理就是削峰的一种实现方式。

内存缓存:秒杀系统最大的瓶颈一般都是数据库读写,由于数据库读写属于磁盘IO,性能很低,如果能够把部分数据或业务逻辑转移到内存缓存,效率会有极大地提升。

可拓展:当然如果我们想支持更多用户,更大的并发,最好就将系统设计成弹性可拓展的,如果流量来了,拓展机器就好了。像淘宝、京东等双十一活动时会增加大量机器应对交易高峰。

架构方案

一般秒杀系统架构

设计思路

将请求拦截在系统上游,降低下游压力:秒杀系统特点是并发量极大,但实际秒杀成功的请求数量却很少,所以如果不在前端拦截很可能造成数据库读写锁冲突,甚至导致死锁,最终请求超时。

充分利用缓存:利用缓存可极大提高系统读写速度。

消息队列:消息队列可以削峰,将拦截大量并发请求,这也是一个异步处理过程,后台业务根据自己的处理能力,从消息队列中主动的拉取请求消息进行业务处理。

前端方案

浏览器端(js):

页面静态化:将活动页面上的所有可以静态的元素全部静态化,并尽量减少动态元素。通过CDN来抗峰值。

禁止重复提交:用户提交之后按钮置灰,禁止重复提交

用户限流:在某一时间段内只允许用户提交一次请求,比如可以采取IP限流

后端方案

服务端控制器层(网关层)

限制uid(UserID)访问频率:我们上面拦截了浏览器访问的请求,但针对某些恶意攻击或其它插件,在服务端控制层需要针对同一个访问uid,限制访问频率。

服务层

上面只拦截了一部分访问请求,当秒杀的用户量很大时,即使每个用户只有一个请求,到服务层的请求数量还是很大。比如我们有100W用户同时抢100台手机,服务层并发请求压力至少为100W。

采用消息队列缓存请求:既然服务层知道库存只有100台手机,那完全没有必要把100W个请求都传递到数据库啊,那么可以先把这些请求都写到消息队列缓存一下,数据库层订阅消息减库存,减库存成功的请求返回秒杀成功,失败的返回秒杀结束。

利用缓存应对读请求:对类似于12306等购票业务,是典型的读多写少业务,大部分请求是查询请求,所以可以利用缓存分担数据库压力。

利用缓存应对写请求:缓存也是可以应对写请求的,比如我们就可以把数据库中的库存数据转移到Redis缓存中,所有减库存操作都在Redis中进行,然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中。

数据库层

数据库层是最脆弱的一层,一般在应用设计时在上游就需要把请求拦截掉,数据库层只承担“能力范围内”的访问请求。所以,上面通过在服务层引入队列和缓存,让最底层的数据库高枕无忧。

案例:利用消息中间件和缓存实现简单的秒杀系统

Redis是一个分布式缓存系统,支持多种数据结构,我们可以利用Redis轻松实现一个强大的秒杀系统。

我们可以采用Redis  最简单的key-value数据结构,用一个原子类型的变量值(AtomicInteger)作为key,把用户id作为value,库存数量便是原子变量的最大值。对于每个用户的秒杀,我们使用  RPUSH key value插入秒杀请求, 当插入的秒杀请求数达到上限时,停止所有后续插入。

然后我们可以在台启动多个工作线程,使用 LPOP key 读取秒杀成功者的用户id,然后再操作数据库做最终的下订单减库存操作。

当然,上面Redis也可以替换成消息中间件如ActiveMQ、RabbitMQ等,也可以将缓存和消息中间件 组合起来,缓存系统负责接收记录用户请求,消息中间件负责将缓存中的请求同步到数据库。

本文介绍了通过一个map替换字符串中指定的字符变量方法,非常实用,有兴趣的同学快看看吧

项目中需要生成一个合约,存放在mysql对应的text类型的属性里,

合约的内容对于每个用户来说大致都一样,但有几个地方需要替换成对应的信息,

比如,甲方,乙方的名字,合约的日期,合约的金额。

本来想找个第三方的jar包来实现这个功能,但找了很久都没有合适的,于是自己写了个简单的方法。

 

 代码如下复制代码

packagecom.test;

 

 

 

 

importjava.util.HashMap;

 

importjava.util.Map;

 

 

 

 

publicclassStringFormat {

 

 

 

 

    publicstaticString format(String input, Mapmap) {

 

        // 遍历map,用value替换掉key

 

        for(Map.Entryentry : map.entrySet()) {

 

            input = input.replace(entry.getKey(), entry.getValue());

 

        }

 

        returninput;

 

    }

 

 

 

 

    publicstaticvoidmain(String[] args) {

 

        Mapmap =newHashMap();

 

        map.put("$1","value1");

 

        map.put("$2","value2");

 

        map.put("$3","value3");

 

        System.out.println("结果:"+ StringFormat.format("$1$2$3", map));

 

        // 结果:value1value2value3

 

    }

 

 

 

 

}

 

标签:[!--infotagslink--]

您可能感兴趣的文章: