Redis系列-9.命令总结

文章中可能有地方描述偏差，欢迎留言指证

1.基本

这节内容不多，主要是对前面的文章做一个总结和给初学者一些建议

2.总结

redis的命令是unix式命令，在前面的命令中我看到这么几点：
1.命名都不长，是一些缩写和简写
2.全程命令控制，和linux上非常像。
3.如参数过多，可能会输错

针对第一点，对我这样写管了C#代码的人来说，有一些需要适应的地方。我喜欢在C#中尽量表明我的意思，而redis作者的想法我估计是让熟悉的人更快的使用。命令在使用上达不到看命令就完整的知道要干嘛，需要查看一些文档和熟练的过程。但是对长期使用redis的人来说，用起来会非常快。对redis这样的高性能要求程序，简洁的命令正是他所需要的，键名的长度都对性能有影像呢！所以我们在做事时，有时需要为一些要求来牺牲一些东西（比如追求高性能用C++，在时间和金钱上的开销会大的多）。

针对第二点，我在以前大学上路由器交换机这类课时就问过老师，为什么发展了这么久，还是用命令式控制而不是GUI呢？我老师说是为了性能要求，在那种需要性能的设备上，命令式系统会做到最小而性能最高。这话放在redis上也是一样的。同时redis也支持一次导入文本中准备好的命令。单一的输入接口在使用起来之后会非常高效。同时我认为这类场景的设备或程序可能长期会是命令行控制。理由是这种方式在人员熟悉了之后会保持很好的性能和效果，对一个熟悉命令的人来说，输入命令会比鼠标点击方便和快的多。对开发者来讲，在了解redis的运行之后，也顺便了解下其它的方式。。你能详细在Linux的VIM上，全是键盘写代码吗？如果一个项目超几千行，这样的编辑方式会让人抓狂吧。。

针对第三点，在以后的使用中，不会让我们手动去敲这样的命令。我问过已经在使用redis的人，他们说是用一些驱动去做。我估计类似ado.net和sql server这样的关系吧，或是有更好的方法。PS：ado.net在C#里，是把SQL语句传递给sql server数据库去执行，EF也是基于这个来做的，只是EF把以前自己写SQL语句的过程自动化了。

3.建议

3.1在学习时 多思考作者为什么要这样设计，为什么要设计这个东西

虽然大部分情况下，我们只需要使用就好了，但是做为一个开发者或是一个IT人，不应该保持学习么？redis我认为是一个非常好的，认识什么叫优秀产品的东西。作者在设计redis时考虑了很多，我认为这是非常值得我们学习的。比如5种数据类型的内部实现，比如内存上的处理（后面文章中会有）。在不考虑算法的情况下，这些考虑的周全，正是菜鸡们应该学习的。毕竟一个简单，高效，高可用的程序是每一个开发者都想要达到的目标，redis正好开开眼。

3.2有算法相关需求的，可以去看看redsi的源码

redis是用C语言写的，只有几W行代码。对一个使用了这么多地方的数据库来说，这是非常简洁了的。我虽然还没有去看源码，但从redis的设计优秀上应该能猜到作者在软件设计架构上一定也非常好，那么阅读起来也很清真了。需要算法技能的，就专门去看看他的查找算法，调度（集群那块可能有）这方面的代码。需要软件设计相关的，可以看看他总体的架构设计和考虑。需要更高性能或更多功能，参考源码后可以自己根据需要修改redis。

3.3命令？

命令我不建议专门去记，除了我前面写到的，还有更多的命令，全记是记不过来的。在记一些基本命令后，可以去下面网站上搜：
1.http://www.redis.cn/commands.html 中文的redis官网，和英文版的没有差不少，毕竟现在redis是社区一起在服务
2.http://doc.redisfans.com/index.html 一个专门查命令的网站

4.后续

后续还会有一些使用上的文章。后面的主要的是怎么用redis。redis更高级的在使用上是需要权衡的，就是要按实部分需要去配置和设计对应的数据结构。redis这个东西不是简单粗暴的拿来用就好了，切记！