xcaspar xcaspar

Rainbow Table

@(Web安全)[rainbow]

介绍

彩虹表是一个预先计算好的，用于破解hash密码的文件。它和暴力破解相比，使用更大的存储空间，但是破解时间较短；和简单的散列查找相比，使用时间较长，但是存储空间少。

背景

起初人们可以通过字典穷举的方法进行破解，这对简单的密码是可行的，但是对于复杂的密码，则会产生无穷大的字典，为了解决字典大小，减少产生和查找字典的时间，所以采用了哈希链接的方式用于存储字典。

原理

彩虹表存储预先计算好的hash chain。例如 P代表可能的密码集合，Q是hash后的集合，即Q=H(P);

RESTFUL API设计要点

@(系统架构)[restful]

1. 设置API专属域名，例如 https://api.example.com
2. 将API的版本号记录到URL中，例如： https://api.example.com/v1
3. API网址中不能有动词，只能名词，而且所用的名词和数据库表名相对应，api中的名词如果是个“集合”,则应该使用复数。例如：
https://api.example.com/v1/zoos
https://api.example.com/v1/animals
4. 使用HTTP协议来操作资源：

遇到的问题

####1. MAVEN更新依赖包问题在包版本号相同且你本地已经有相应的jar包，此时clean install自己的工程是不会更新已有且版本号相同的jar的，应添加强制更新参数： clean install –U

####2. Hessian使用BigDecimal问题** 使用hessian远程调用对象时，如果对象中包含BigDecimal属性，则得到的值会是0。解决方法：
在 hessian.jar 的 META-INF/hessian 目录下加入 serializers 和 deserializers 这两个文件, 两个文件的内容分别如下： java.math.BigDecimal=com.caucho.hessian.io.StringValueSerializer
java.math.BigDecimal=com.caucho.hessian.io.BigDecimalDeserializer

MapReduce任务的执行总流程

@(Hadoop)[mapreduce]

介绍

在main()函数中写入JobClient.runJob(conf),然后将程序提交到Hadoop上，一个MapReduce作业就可以在Hadoop上运行，一个作业的执行流程是：代码编写->作业配置->作业提交->Map任务的分配和执行->处理中间结果->Reduce任务的分配和执行->作业完成，而在每个任务的执行过程中，又包含输入准备->任务执行->输出结果。流程图如下：
从图中可以看出MapReduce作业的执行可以分为11个步骤，涉及到4个独立的实体。它们在MapReduce执行过程中的主要作用是：

客户端：编写MapReduce代码，配置作业，提交作业。
JobTracker:初始化作业、分配作业，与TaskTracker通信，协调整个作业的执行；

MongoDB中MapReduce的使用

@(mongodb)[mapreduce]

介绍

MapReduce是一个编程模型，封装了并行计算、容错、数据分布、负载均衡等细节问题。MapReduce实现最开始是映射map，将操作映射到集合中的每个文档，然后按照产生的键进行分组，并将产生的键值组成列表放到对应的键中。化简（reduce）则是把列表中的值化简成一个单值，这个值被返回，然后再次进行键分组，直到每个键的列表只有一个值为止。

代码实现（部分重要代码）

例如有一文档user，结构如下：

MongoDB数据迁移

@(mongodb)[数据迁移]

主要使用mongodump和mongorestore命令，我把迁移工作分为以下操作： - 先查询现有MongoDB数据库的数据量，目的是比对迁移后的数据量，查看用户数据有没有丢失。我用了比较笨的方法进行查询，由于我确信不会有新数据插入，所以我直接查询集合文档数量：
db.库名.集合名.count() - 创建所用目录：有MongoDB导出目录和新的数据存储目录。在新的磁盘上创建文件夹,使用mkdir命令，目录结构要确定好，便于以后维护：

项目重构总结（二）

@(工作) ####介绍接上篇，上次重构后的设计是，按业务划分，通过交易模式和游戏类别来生成相关的交易业务Service，将相同的业务方法写到抽象父类的方法中，抽象父类对外只暴露业务接口方法，这样保证了业务入口的一致性，防止业务方法被部分调用的错误。不同游戏、不同模式的业务方法写到相关的子类中，保证业务方法的特殊性。

问题

但是由于需要接入营销平台SP系统，SP系统又有各种各样的业务、活动，对交易业务逻辑要求不尽相同，上次重构后的系统要想满足SP系统的多态化交易模式，必须为每个业务处理重新写一整套交易流程，包括下单、支付、发货等，这样会使工作量大增，而且不好维护，同时在工厂中新增一遍实现类，感觉不是很灵活。上周根据这种需求又重新设计了一下交易系统设计。

重构

交易系统还是按业务Business来划分（下单、支付、发货、打款等），但是将原来的业务实现拆分成多个“原子方法”Action，每个Action下可以包含多个子Action；单个业务的实现是将“原子方法”Action进行排序组合，相同业务但不同处理就可以选择不同的Action和组合方式；当新增一种业务处理时，只是新增Action，同时可复用原来的Action，大大减少了代码量，并且增加了灵活性。目前这些Business和Action都是可配置的，可根据业务进行不同配置。如下图

项目重构总结（一）

@(工作) ####介绍项目系统间是通过接口进行业务调用，业务目前分B2C和C2C两种交易模式，不同游戏在相同或者不同的交易模式下，校验、支付、商品交互、发货等业务处理也不一样。这就形成相同场景下不同的业务处理需求。重构前的代码部分采用了工厂模式和抽象工厂方法，但是由于抽象工厂方法的原因导致结构设计特别冗余，编码起来特别繁琐，修改起来更麻烦。重构前还有一个不好的地方是B2C和C2C的校验是放一块的，通过交易模式来划分，但是如果不同游戏的校验不一样的话，很难扩展。

重构

重构后的设计是，按业务划分，通过交易模式和游戏类别来生成相关的交易业务Service，将相同的业务方法写到抽象父类的方法中，抽象父类对外只暴露业务接口方法，这样保证了业务入口的一致性，防止业务方法被部分调用的错误。不同游戏、不同模式的业务方法写到相关的子类中，保证业务方法的特殊性。拿下单校验举例，代码如下：

public class TradeFactory {

	You are Manus, an AI agent created by the Manus team.

	You excel at the following tasks:
	1. Information gathering, fact-checking, and documentation
	2. Data processing, analysis, and visualization
	3. Writing multi-chapter articles and in-depth research reports
	4. Creating websites, applications, and tools
	5. Using programming to solve various problems beyond development
	6. Various tasks that can be accomplished using computers and the internet