修改del命令为kdel,添加更适配twemproxy的del命令

[jerry-yuan]

ideawu,您好: 对于Redis协议中del命令无法删除除Key-value以外(hash,zset,queue)的数据,在#810与#1178中均有提到. 对于这个问题您在问题#810中的答复为先知道类型再进行删除的方案,这一点我是认同的,从您的源码也能看出这样的设计原则.但是在某些情况下,使用SSDB自定的命令可能不太合适. 如果是单实例的SSDB,客户端直接连接SSDB,直接发送自定义命令hclear/zclear/qclear即可删除对应的数据,但是如果是SSDB集群,并且使用twemproxy进行负载均衡以及容量扩充,由于twemproxy的问题,其本身连一些redis的命令都无法做到支持(比如flushdb,keys之类的,不支持也情有可原),对于SSDB所定义的这些更加特殊的自定义方法并不能很好的进行转发(会导致TwemProxy断开连接).在此场景下,唯一能够对数据库中数据进行删除的命令就只剩del了,而ssdb的del专指(key)del,这将导致在此环境下,SSDB只能增加hash/zset/queue的存储,而不能进行数据的删除.

请您原谅我冒昧提出的Pr.我所更改的部分只是将原本属于key-value的del命令更改为kdel,并将原来del/hclear/zclear/qclear四个函数所做工作集中整合至新的del命令,代码与原来的部分基本一致,所以对于主从部分场景下的功能没有做测试,如果有什么bug在里边,还希望您能斧正,谢谢.

[ideawu]

Hi, 建议只修改网络层, 增加 kdel 命令, 这个命令只是调用 del 命令. 这样, PR 改动的地方越少越好.

[jerry-yuan]

您希望尽量少改动接口的想法我能理解,毕竟已经有这么多的应用在使用SSDB,一个接口改动可能会导致既有项目的不兼容.但是不改动del命令只增加kdel仍然无法解决twemproxy应用场景下的问题(twemproxy只支持del命令和multi_del命令的传递),同时现在发现multi_del的操作和redis协议定义的行为不一致,提交PR之后我又对multi_del做了类似的改动. 在做更改的过程中我也考虑过是否可以在配置文件中定义出兼容模式的标志,在兼容模式下,尽量遵守Redis协议规定的既有命令的行为特征(比如del删除所有类型下的指定key),我不知道这这样做是否合适(会导致更多的代码更改),所以只是做了一些简单更改而没有增加相关的配置项目.

除此之外,您所说的网络层指的是NetworkServer类相关的内容吗?现在我的想法就是不改动SSDBServer类相关的代码,只是将NetworkServer的proc_map中del命令改到了kdel命令,增加一个兼容Redis协议的del命令及其处理函数.最开始我的想法是用这个新的proc_del函数中去调用proc_kdel(改名自proc_del)/proc_hclear/proc_qclear/proc_zclear函数,但是发现您的这些函数可能会导致提前向客户端响应ok,所以只能选择把代码复制一遍.

另外现在这个PR来看,貌似我的编辑器动了不少您的既有代码格式,我对我的疏忽表示非常抱歉,如果您认为改动后的代码格式不符合合并要求,您直接驳回PR即可,我可以重新整理后再提交合并请求(当然是您认可代码的情况下).