这又是一个非常具有争议的话题
居然半个月没写了，实在是懈怠了。
估计的人群有
A：支持的。这种以我为代表的一批人。觉得不管不行，迟早战火会烧到数据库这里。
B：不支持但是也不反对。觉得自己就是应该逆来顺受的。也喊出来一种道义上的制高点。技术是为了业务服务的。（似乎有点军事斗争是为政治斗争服务的意思）
C：反对的。有些一直觉得开发应该取代DBA的。觉得不配去管理。
D：各自管好自己就行。不要越界。诚然如果一个团队每个人都完成自己的分工，能自扫门前雪也行啊。但是实际上，几乎都是要去补位。这种其实都有。就看谁多了。
节后第一天接到别人求助说，他们的Redis堵塞了。（说到这里，顺便说一下，不少人觉得Redis、ES等不算数据库，这点我始终不认同。凡是DB-engine上有的都是。反而Oracle的OGG，纵然是甲骨文的产品，纵然是连接多种数据库的桥梁，我也不认为OGG是数据库）
Redis的堵塞不常见
这里的堵塞我其实也是第一次见。这个是在client信息中出现了blocked_clients。出现了27个。
从数据库角度看这个堵塞可能最先想到的是slow-SQL。看了一下确实有，但是他几乎不更新。我尝试删除了几个堵塞的会话，然后他又恢复了。还是27个。很奇怪是吧？
具体整个排查过程真的值得写一下。我打算把他写到第二本书中去。现在还在目录阶段。
最后我发现是应用程序的设计问题
27个大的列表，不断的写入和读出。你可以理解为一个消息队列。虽然说Redis支持消息队列的这种应用。这个我在第一本书中介绍过。
但是吧。支持也有个前提条件。毕竟不能当做kafka用。
就像数据库的多模是可以解决异构数据库的融合，但是极致的应用的话，还是差点意思。这就像不少数据库说兼容谁谁谁。但是如果是深度应用的话，还是不行。这种深度不是说使用了存储过程就是深度。10行的存储过程，那叫兼容。10万行的存储过程，那叫深度应用。
所以我一般和人交流，有的企业说我们已经不让用存储过程了。好像不用存储过程就不深度了。结果SQL写的复杂的不亚于存储过程。
我们说的多模是通用场景的。那么如何才能把握这个度。显然开发人员未必熟悉，甚至可以说几乎不懂。因为关注点是业务逻辑。所以怎么用，还是DBA更加有发言权。
数据库就像一个产品，他有他的说明书。遗憾的是开发人员不看。其实即使DBA也未必全看。但是还是有人看的。当大家遇到问题时候，要么问人，要么看说明书就是这样。
有时候的灵魂拷问
有时候开发人员会问，这个字段可以吗？这个表可以吗？这个索引可以吗？我会一一作答，问你这个场景是什么？需求是什么？以后打算怎么扩展？怎么操作数据和怎么检索？
然后我会指出，这样的话，不能这样做，应该如何做。之所以这样是一次次的教训让大家知道，不这样就会出问题。
对于看不起数据库和DBA的人来说，为什么要设计这么复杂的产品和说明书？
那就去看看法律，各种法律各种条款也不少。那怎么不简单一点？法律我不擅长，只是知道多一个字和少一个字都不行。有些东西不是设计者不想简单，是情况太复杂了。
不仅要管还要从源头管
如今数据库有RDBMS和NoSQL，以及NewSQL。再加上国产数据库等，已经数不清了。DBA应付这些都已经很吃力了。这些上面的坑和最佳实践还是DBA相对了解的最清楚。所以最佳的解决方案还是从源头开始管理开发任务。
除此之前还要卷中间件、硬件、消息队列、操作系统等。这些领域作为数据库的周边，开发人员深入的程度可能还不及数据库。使用不当和用错，不说是板上钉钉吧也可以说十有八九有问题。各式各样的妖孽问题层出不穷，最后还会使得系统的成本上升。