如题，本来我的开博随笔是在CSDN里写的，也准备发到CSDN里去，然而昨天一早提交发布很快审核通过之后，在【我的CSDN】主页和CSDN的App里都看不到文章，在CSDN网站也搜索不到。
最开始我以为这仅仅是个数据同步问题。
CSDN的文章管理是一个单独的域名，后台多半是个独立的应用，我们姑且称之为应用1；【我的CSDN】应该是个针对用户／博主的用来管理文章和发布设置的独立系统，我们称之为应用2；【blog.csdn.net】这是面向所有用户的用来展示文章的门户前端，我们称之为应用3；CSDN的App，我们称之为应用4。那么，在应用1里，某博主写了一篇文章，提交审核；在应用1的后台，会有网站的编辑先审稿，审核通过之后，就可以把新文章发布到剩下的3个前端展示系统里去了，我猜测大致应该是这样的。那在一般的网站或者业务系统里，如何在这种场景下处理数据呢？
方案一、4个应用共用一个数据库就好了，这样所有修改都能实时查询到。但因为应用3、4要应对可能的高并发访问，应用1、2则属于低频的业务数据产生来源，所以可以用轻量级数据库（比如mysql）做集群，做读写分离，让应用1、2去使用写入库，靠数据库同步来简单的满足需求。
这种方案是可行的，很多网站也是这么做的。但对于CSDN这样的网站来讲，这个方案则显然不太够用。因为CSDN是社区性质的，每篇文章可以有很多的评论，还可以回复。如果用传统的RDB来保存所有数据，查询的开销会非常大。（至少，评论／回复数据不能和文章数据放在一个表里，也就是说展示一篇文章时，至少需要一个多表查询；即使做了索引优化，当数据量非常大时，其性能也不容乐观。）这个情景其实与微博很像，这种明显的非结构化数据，用nosql数据库存储显然更为合适。因为nosql数据库更多的是面向数据查询（展示）的，传统的关系型数据库（RDB）其长处则在严格的数据结构以及存储、计算上的效率。基于这种思路，我们可以在文章相关的数据存储上做一个小改进。
基于方案一，把文章相关的数据从RDB中剥离出来，保存在nosql数据库（比如mongodb）中；即把针对一篇文章的所有评论、回复数据都保存到同一个document里。这样，展示一篇文章的时候，只需要一个主键查询，就能把文章相关的所有评论、回复数据一并取出，展示给用户。有评论、回复增加时，直接更新这个document即可，不需要再去访问主数据库。
但看CSDN现在的功能，应用1、2、3、4所使用的数据和展现方式都有很大的不同，除了用户数据、文章内容数据可以通用以外，再没有太多可以共用的东西，所以我猜测，它们是4个独立的系统，前后端乃至数据库很可能都是异构的。如果是这样的话，那就一定会有数据同步的问题。
方案二、前端展示应用3、4使用RDB+nosql的混合存储方案，提高查询、展示数据的效率，应用1、2使用一套RDB来管理用户、文章相关的结构化数据。应用3、4用后台任务定期（一般会是数十分钟乃至数小时的频率）从应用1、2使用的数据库中同步数据的改动，同时更新搜索数据库。
这里简单说下搜索数据库的概念。像CSDN这样的大量内容的网站，一般会有全文搜索功能，这类似于百度或者google那种搜索引擎的功能。全文搜索的结果，肯定不是实时给出来的，而是后台代理在不停过滤内容，根据关键词整理出来的；简单讲，就是事先算好的。这也是为什么我们刚刚创建的网站、网页，没办法马上在搜索引擎里体现的原因，因为搜索引擎也一样需要时间去“收录”新的内容，与之相应的，也就有了所谓SEO（搜索引擎优化）这类的概念。搜索引擎是个很有技术含量的领域，同样，全文搜索相对也不是个很简单的东西。因篇幅所限，这里就不继续展开了。
这种方式的缺点很明显，实时性差。我写一篇文章，可能要等一两个小时别人才能看到，才能被搜索到，用户体验是不好的。而且这种模式，还是有数据库共用的问题，某个应用压力增大的时候，很可能也会影响与其共用数据库的应用。但这种方式是在一些应对异步数据处理的中间件产生之前，最通用的处理方式；也是大部分结算、报表等等需要大量运算以及对实时性要求不高的业务场景下最常用的方式。对于CSDN这种网站来讲，这当然不是个好方案。所以如果现在来设计的话，我们多半会采用下面这种方案。
方案三、4个应用完全解耦，分别使用自己的前后端和数据库，采用最适合自己功能的存储方案（即根据自己的功能及展示需求选择只使用RDB／只使用nosql／混合存储），采用消息中间件（比如类似于Kafuka的产品）来做数据同步。
发布订阅模式的消息中间件，对分布式系统／异构系统间的通信能力是一个巨大的提升。简单讲，应用1可以在MQ（消息队列）中创建一个topic（主题），应用2、3、4可以subscribe（订阅）这个topic。当有博主创建一篇文章之后，应用1可以往这个topic下发布一个messsage（消息），应用2、3、4会接到通知，然后去该topic下取得新的message，根据message内容，做自己的数据同步／增量更新。这种方式的处理性能，是先前的定期数据同步方式所难以望其项背的。
这种方案大概是最现代的设计，也是现今逐渐成为主流的微服务架构的思路。关于微服务架构，当然还有很多可以讨论的内容，这里也不再展开了。
我想各位看官已经明白了，我说了这么多，其实是在讲后端存储架构的一个演化／改进的思路，也大概是近10年来数据存储架构的变迁历史。当然，上边提到的每个方案都还有很多细节可以讨论，有很多可以改进的地方，但这已超出本文的范畴。因为我还要回到在CSDN发博失败这件事上。
一小时过去了，两小时过去了，一天过去了，两天过去了；到现在，我的文章还是没在我的个人主页上显示出来，在CSDN网站或者App上也都搜索不到；所以我们可以知道，这应该是CSDN的文章管理系统的bug！我的天哪……
第一天下午的时候，我也联系了CSDN的QQ客服，可惜在我说明情况之后，就没再获得回复。对此，我也已经彻底失望了。所以我昨天才到简书上开了账号，传了文章，发了开博随笔。
最后，我想说，对于CSDN这种名气的网站来讲，这种问题应该存在么？发了文章，除了我自己，谁都看不到？这是CSDN应该出的bug么？虽然这个事和2011年那个著名的明文存储密码的事件相比可能不算什么，但这么多年过去了，CSDN还是这种水平，实在让人扼腕叹息。从产品的角度讲，出了一次这种问题，还想用户能用你的东西么？界面风格杂乱、不美观这些都不谈了，但文章都发布不出来？如非亲身经历，真的很难想像我这是在用CSDN。
我不相信这个问题只有我一个人遇到，我也不相信那么明显的界面风格不统一没有别人发现，我想这就是那个团队根本没人用心。也许我们不该要求一个非营利网站要做的像互联网巨头那样好，但在我看来，CSDN根本不及格。
我想我们工作、做人，都不应该是这种不负责任的方式。
