创建的Redis对象是否可以提供String和序列化两种可选方式的配置

由于Redis的很多命令针对String和Object都有不同的结果，有时需要操作纯字符串，这个序列化的选择应该是可选的猜对，保持Redis官方默认的数据类型String类型。

举例：INCR/INCRBY/DECR/DECRBY/HINCR/HINCR…… 等各数据类型的加减计算原子操作，只能对String类型数据进行计算，而这个命令在项目中用到极多，比如top计算，统计加减等。

@LarryKoo 有个疑问：

楼主对String的序列化可选方式配置，是永久性的还是说在调用时可以随时切换这个配置？前者很容易，后者比较麻烦，后者麻烦之处在于从redis中读取到一个数据时，你无法确定是否需要反序列化，这就是 jfinal 为何将数据一律进行序列化的本质原因。

另外 jfinal redis所有api中的key值处理，都没有进行序列化，所以 incr/incrby 这些都是支持的，而且这些api中的参数，例如long型参数都是没有序列化的，没明白楼主具体是指什么问题？

具体需求就是在项目会同时用到序列化存储和String的数据存储，是永久还是可配置目前还没有想到比较好的解决方案，初步设想:第一种方法是RedisPlugin初始化的时候新增一个是否序列的的参数；第二种是暴露两个Redis操作接口在外面，如：Redis.use()/SRedis.use()

incr/incrby 命令是对value进行原子加减操作，序列化肯定是不支持的，跟key没有关系的。

下面是Redis文档INCR原文翻译：

提醒：这是一个string操作，因为Redis没有专用的数字类型。key对应的string都被解释成10进制64位有符号的整型来执行这个操作。

总结：类似value必须为整型的一些命令，都是不能使用序列化存储的，智能是String操作。

@LarryKoo issue 已备忘，下次版本开发想个设计方案。只有自动化决定是否要序列化和反序列化才是完美的，感谢反馈

@JFinal 我们一直在努力，哈哈；

貌似序列化之后的数据有一个标记的，研究中……

@LarryKoo 研究结果记得反馈哈，jfinal 改进一下

GVP JFinal / JFinal