十年网站开发经验+多家企业客户+靠谱的建站团队
量身定制+运营维护+专业推广+无忧售后，网站问题一站解决
作者：张泽华
业务需要
1.为什么说是业务需要？
——先来了解下阿里在上线AliDNS之前已经做了哪些事儿。
阿里的架构变迁可以说是针对业务的一次完整进化。从最初的单台服务器跑起少量的业务开始，到今年571亿的双十一绝不是一蹴而就的。作为一家较大的电商网站在互联网应用系统中要面对极多问题：高并发，高可用，安全环境较差，客户分布广泛，网络环境较为复杂等等。
为满足复杂的需求，网站的架构逐渐从单机服务演进到：前端是各地的CDN服务器集群，连接各反向代理服务器集群，连接负载均衡服务器集群，接下来将访问请求转到按照业务划分的应用服务器集群上，通过消息队列集群传到分布式服务集群上，然后通过缓存或一致性数据访问模块连接到数据源：分布式缓存、分布式数据库、分布式文件集群，外加NoSQL和搜索引擎服务器等等。
imgsrc=""data-rawwidth="1201"data-rawheight="750"class="origin_imagezh-lightbox-thumb"width="1201"data-original=""/*/*大致就这么个意思，尤其突出了DNS的作用*/
架构演进到这里不难发现有两个明显的特点：分层化和分布式。优秀的工程师们将这种能够应对复杂业务逻辑和数据处理的海量数据和高并发的架构进一步设计为平台化的方式，不仅能够服务当前企业，还能够将资源作为一种产品出售，这样让各类小型网站享有架构便利性的同时只要按需付费即可。这样，阿里云就诞生了，其实它是技术演进过程中的一个必然产物，这也不难理解Google、Amazon、Alibaba等超大规模互联网公司对外提供的云计算服务。
DNS服务是将阿里的域名解析成IP地址，不仅可以利用DNS实现DNS的负载均衡，并且在配置运营商CDN机房时也是重要的一部分。DNS技术属于前端架构甚至更前的一部分，不难看出一个大型网站在提供好扎实的应用层和数据层服务后亟待解决的是访问的问题，访问安全问题也是伴随着要解决的问题之一。
所谓访问的问题：
1.能够保证客户顺利的连接上网站
2.能够保证整个过程的安全
3.快
2.DNS服务了什么？
贴一下阿里DNS的自我介绍：阿里DNS
阿里公共DNS简介
阿里公共DNS是阿里巴巴集团推出的DNS递归解析系统，目标是成为国内互联网基础设施的组成部分，面向互联网用户提供“快速”、“稳定”、“智能”的免费DNS递归解析服务。
一、DNS简介
DNS是互联网上存储域名与IP映射关系的一个分布式数据库。使用DNS，用户可以方便的用域名访问互联网，而不用关心复杂难记的IP地址。通过域名获取对应IP地址的过程叫域名解析。
域名解析一个相对复杂的过程，需要多个环节，遍历多个DNS服务器，才能获取域名的IP地址。解析过程见下图：
二、用户使用DNS面临的问题
大部分用户使用的LocalDNS是用户在接入网络时由ISP自动分配的。存在几方面问题：
三、阿里提供公共DNS服务的优势四、阿里公共DNS的特点
快速:
稳定:
智能:
结束语
阿里公共DNS的目标是成为国内互联网基础设施的组成部分，为国内互联网的健壮、稳定、快速贡献我们的力量。
结合阿里优质CDN资源和精准的IP地址库，让用户访问到较近的网站。
异地多机房高可用架构。
基于DPDK自主研发的高性能DNS系统。
Aliguard多种攻击防御策略。
持久化保存热点记录，当“根”或域名的权威DNS出现异常后，阿里公共DNS具备快速恢复正常访问的能力。
通过BGPanycast技术，让用户访问到离自己较近的DNS集群。
主动缓存热点域名的，提高查询CACHE命中率，减少递归过程，快速应答。
阿里在全国有优质的机房、网络、带宽等互联网基础设施资源。
阿里建设和运营着全国最大的CDN网络，对互联网流量调度有丰富的经验。
阿里旗下万网是国内最大的域名注册商，管理着几百万域名。同时有丰富的DNS管理经验。
阿里拥有大量优秀的技术人才，有非常强的自主研发能力和运维保障能力。
域名解析的环节较多，其中任何一点出现问题，都可能会导致解析异常，进而影响用户对互联网的访问。
当前互联网上CDN很多都是根据LocalDNS的地址来调度。有些ISP的LocalDNS并不直接去递归解析，而是转发到其他LocalDNS上，可能导致CDN调度不准确，使用户不能访问到最快的站点。
ISP不是专业的DNS服务商，提供的LocalDNS可能出现性能、稳定性等方面的问题。另外，日益频繁的DNS攻击，也会导致LocalDNS出现宕机、劫持等情况。这些都会影响客户的上网体验。
简单翻译一下就是：
1.我家DNS速度快。|特别是保证秒杀反应快
2.域名解析到我这里靠谱。|特别双十一不瘫痪
3.我的数据更新快。
4.根据我的GeoDNS能够知道你到底是从哪里访问的，给你一个最快的服务器服务。
5.我的DNS特别稳定。
6.有些无良的DNS提供商会给你乱装软件，乱弹窗口，卖假药什么的。
调侃一句：如果说下一步阿里要做什么，估计是要自己做Tier1运营商了。
------------------------------------------------插入点技术部分-----------------------------------------------------------
DNS迭代，递归查询是啥？
出于资源消耗和响应速度的综合考虑，一般来说从主机到本地DNS服务器是递归查询，从本地DNS到其他DNS服务器是迭代查询。
详细解释：DNS查询的工作原理
BGPanycast是啥？
从域名可以解析出来很多个主机IP地址对应，那DNS服务器只有一个IP地址可不是只有一台。为了让一个IP地址对应分布在各地的多台DNS服务器，采用anycast(任播)将数据发送到一组目标节点上，通过路由协议选择"路由矢量最近点"提供“最快”的服务。可以应对DOS攻击和网络拥塞。
主动同步万网注册域名是啥，其他能同步吗？
万网被阿里买下了，内部数据同步下快还不行么。其他时限不一定，看同步间隔。
--------------------------------------------------------------------------------------------------------------------------------
业务拓展
从阿里云在阿里中的技术和商业定位中可以看出：
为了满足自身电商等业务的正常运行和服务
为了让云计算资源作为服务型商品卖掉（剩余资源的充分利用，在固定投入不变的情况下的单位效率提升）
重点说第二点，云计算资源的服务。
imgsrc=""data-rawwidth="587"data-rawheight="418"class="origin_imagezh-lightbox-thumb"width="587"data-original=""
前面也提到的快速安全的访问在当前中国几大ISP的管控下谈安全快速访问就是扯淡。扯淡对普通百姓来说可能感觉就是右下角总是弹窗，或者说你家路由器不能用，或者说这个知名网站又打不开了，或者说“咦，电信那边的网站怎么被屏蔽了？”大家互相扯皮和撕逼倒是正常的，但是人家阿里的生意还是要好好做的，不能在这欢乐的撕逼战中成为炮灰，或者是在无限的弹窗中链接跳转到的某某其他购物网站，马总的想法是让天底下没有难做的生意，我阿的访问要成问题我还让我商家的生意怎么做？
另外作为一个需要VPS服务的程序猿，当我开心的在万网买了域名，备了案（假如我有一天会这么做了）发现在家苦等1天还没生效的时候，你下次还敢买这里的域名，用这家的云计算服务么？其实人家阿里万网挺无辜，在万网的服务器上都是秒级的事儿，但是你懂得的原因就是没有生效。这时候你是不是很期待阿里一统天下的ISP？什么？嫌贵，那你告诉我正在用的2MADSL每月150CNY是什么。。。
如果有幸你能知道有个东西叫DNSSEC，那么恭喜，你又发现一个重大安全隐患。简单来说这个东西就是一部分解决你的DNS查询中的DNS的欺骗和缓存污染问题。除了DNSSEC区域签名以外，云计算服务供应商们还必须在客户用于名称解决方案的递归解析程序中打开DNSSEC验证。
imgsrc=""data-rawwidth="612"data-rawheight="312"class="origin_imagezh-lightbox-thumb"width="612"data-original=""
附上一份我国实施DNSSEC的文件网址：;sno=112
================================================================
====================修正后的答案======================================
PSS.一篇来自乌云社区的帖子，看看就好：百度有钱联盟利用IE漏洞推广安装软件
编辑于2014-12-15
郑叔叔
@张泽华
的答案很详细！
尾部提到的HTTP劫持，我们网站的做法是启用CSP，能起到一定作用。
编辑于2015-02-20
知乎用户
可惜，你们永远也不知道，有一个东西叫做AIXYZDNS。谁用谁知道。
普通。就是学习数据库的操作而已。读取,编辑,删除这三种操作逻辑。只要记忆力好,把那几种命令语句背下来,基本的操作就没问题。这对今后的其他课程尤其是编程是有帮助的,因为有些软件会设计到数据库的读写操作。尤其是一些网站,肯定会连接数据库。不会数据库操作,就没办法制作动态网站。
很多国产数据库乘风破浪
我们正处在一个数据库技术大爆炸的时代。
这几年，NoSQL数据库、NewSQL数据库、时序数据库、图数据库、分布式数据库、超融合数据库等专业数据库技术发展势头很猛，国产数据库的表现也相当亮眼。
过去十年，是互联网发展的黄金十年。与此对应的是业务系统访问并发呈指数级上升，海量数据计算和分析需求越来越普遍，传统单机系统在业务支撑、成本、开放性等方面均面临巨大挑战，数据库垂直扩展模式难以维护等困境。
眼看着数据库性能瓶颈快要扼住发展的喉咙，摆在这些长久依赖Oracle、IBM等传统数据库的巨头们面前的，只有两条路：要么开启无限加量的PLUS模式，即更换更多更强的服务器、硬盘、内存、CPU等，要么自研能满足业务发展需求的数据库。
开拓者们的眼光一开始就聚焦在更长远的未来，他们发现即便是系统变成真正的“傻大粗”，也只是解了燃眉之急，不能从源头解决问题。
再看一眼像Oracle、IBM等传统数据库高昂的拓容价格，像阿里这样的富一代也吃不消哇！
那么，自研数据库，走起！
2010年后，云计算和开源社区兴起，国产数据库开始了弯道超车。
2019年被认为是国产数据库的元年。
这一年，众多国产数据库产品闯入了我们的视线，热度不断攀升；这一年，OceanBase登顶TPCC，并于一年后再次刷新自己的记录。
从刀耕火种到摘下Oracle在数据库领域的皇冠，国产数据库经历的是一段不被理解和不被看好的岁月。
在国外数据库先驱长期占据市场优势的情况下，国产数据库要想杀出重围，一是要付出多倍努力，二是要拿出更强的产品才能在客户面前更有底气。
当然，国产数据库发展至今，已然是百花齐放。未来，国产数据库的发展趋势相对也比较明显，即往云原生和分布式发展。
金融级分布式数据库应运而生
数字时代，数据成为各家必争之地。
在金融应用场景下，国内数据库市场于近几年开始发生变化。
随着应用层和业务层的压力加大，金融机构对分布式技术架构转型的需求应运而生。
作为软件系统的三大底层技术（操作系统、中间件、数据库）之一，数据库成为系统往分布式架构转型的枢纽。
不过，在早年国外传统数据库厂商盘根错节的“蚕食”下，这个核心变得又硬又难啃！
面对如今市场的需求变化，传统数据库系统呈现出一个通病：又笨重又贵。
再是，随着诸如2013年“棱镜门”事件的爆发，各界越来越重视数据安全和技术自主可控。
此外，金融机构对快速、灵活、可伸缩性、创新、敏捷等开发能力需求大大提升，出于对长期IT建设的成本考虑，自主可控更是成为他们出于自身长远发展考量的刚需。
数字化时代，金融机构的整体架构正处于往分布式、云原生、微服务等方向发展的关键时刻，数据库的选型便显得至关重要。
根据中国人民银行发布的《金融科技（FinTech）发展规划（2019-2021年）》，我国将有计划、分步骤地稳妥推动分布式数据库产品先行先试，形成可借鉴、能推广的典型案例和解决方案，为分布式数据库在金融领域的全面应用探明路径，确保分布式数据库在金融领域稳妥应用。
目前已有不少业界实践证明了分布式数据库应用于金融场景的可靠性。同时，金融级分布式数据库云化已经在路上。
肯定是Oracle，因为从简单查询性能角度来比较：OracleMySQLNoSQL，NoSQL产品不支持Join，MySQL的查询优化器由于所基于的统计信息相对少很多，当Query复杂度很高的时候容易出现执行计划不是最优选择的问题，而Oracle由于大量的统计信息支持，使得其查询优化器更为智能，对复杂查询有更优的表现。
闲鱼的IM消息系统作为买家与卖家的沟通工具，增进理解、促进信任，对闲鱼的商品成交有重要的价值，是提升用户体验最关键的环节。
然而，随着业务体量的快速增长，当前这套消息系统正面临着诸多急待解决的问题。
以下几个问题典型最为典型：
1）在线消息的体验提升；
2）离线推送的到达率；
3）消息玩法与消息底层系统的耦合过强。
经过评估，我们认为现阶段离线推送的到达率问题最为关键，对用户体验影响较大。
（本文已同步发布于：）
从数据通信链接的技术角度，我们根据闲鱼客户端是否在线，将整体消息链路大致分为强感知链路和弱感知链路。
强感知链路由以下子系统或模块：
1）发送方客户端；
2）idleapi-message（闲鱼的消息网关）；
3）heracles（闲鱼的消息底层服务）；
4）accs（阿里自研的长连接通道）；
5）接收方客户端组成。
整条链路的核心指标在于端到端延迟和消息到达率。
强感知链路中的双方都是在线的，消息到达客户端就可以保证接收方感知到。强感知链路的主要痛点在消息的端到端延迟。
弱感知链路与强感知链路的主要不同在于：弱感知链路的接收方是离线的，需要依赖离线推送这样的方式送达。
因此弱感知链路的用户感知度不强，其核心指标在于消息的到达率，而非延迟。
所以当前阶段，优化弱感知链路的重点也就是提升离线消息的到达率。换句话说，提升离线消息到达率问题，也就是优化弱感知链路本身。
下图一张整个IM消息系统的架构图，感受下整体链路：
如上图所示，各主要组件和子系统分工如下：
1）HSF是一个远程服务框架，是dubbo的内部版本；
2）tair是阿里自研的分布式缓存框架，支持memcached、Redis、LevelDB等不同存储引擎；
3）agoo是阿里的离线推送中台，负责整合不同厂商的离线推送通道，向集团用户提供一个统一的离线推送服务；
4）accs是阿里自研的长连接通道，为客户端、服务端的实时双向交互提供便利；
5）lindorm是阿里自研的NoSQL产品，与HBase有异曲同工之妙；
6）域环是闲鱼消息优化性能的核心结构，用来存储用户最新的若干条消息。
强感知链路和弱感知链路在通道选择上是不同的：
1）强感知链路使用accs这个在线通道；
2）弱感知链路使用agoo这个离线通道。
通俗了说，弱感知链路指的就是离线消息推送系统。
相比较于在线消息和端内推送（也就是上面说的强感知链路），离线推送难以确保被用户感知到。
典型的情况包括：
1）未发送到用户设备：即推送未送达用户设备，这种情况可以从通道的返回分析；
2）发送到用户设备但没有展示到系统通知栏：闲鱼曾遇到通道返回成功，但是用户未看到推送的案例；
3）展示到通知栏，并被系统折叠：不同安卓厂商对推送的折叠策略不同，被折叠后，需用户主动展开才能看到内容，触达效果明显变差；
4）展示到通知栏，并被用户忽略：离线推送的点击率相比于在线推送更低。
针对“1）未发送到用户设备”，原因有：
1）离线通道的token失效；
2）参数错误；
3）用户关闭应用通知；
4）用户已卸载等。
针对“3）展示到通知栏，并被系统折叠”，原因有：
1）通知的点击率；
2）应用在厂商处的权重；
3）推送的数量等。
针对“4）展示到通知栏，并被用户忽略”，原因有：
1）用户不愿意查看推送；
2）用户看到了推送，但是对内容不感兴趣；
3）用户在忙别的事，无暇处理。
总之：以上这些离线消息推送场景，对于用户来说感知度不高，我们也便称之为弱感知链路。
我们的弱感知链路分为3部分，即：
1）系统；
2）通道；
3）用户。
共包含了Hermes、agoo、厂商、设备、用户、承接页这几个环节。具体如下图所示。
从推送的产生到用户最终进入APP，共分为如下几个步骤：
步骤1：Hermes是闲鱼的用户触达系统，负责人群管理、内容管理、时机把控，是整个弱感知链路的起点。；
步骤2：agoo是阿里内部承接离线推送的中台，是闲鱼离线推送能力的基础；
步骤3：agoo实现离线推送依靠的是厂商的推送通道（如：苹果的apns通道、Google的fcm通道、及国内各厂商的自建通道。；
步骤4：通过厂商的通道，推送最终出现在用户的设备上，这是用户能感知到推送的前提条件；
步骤5：如果用户刚巧看到这条推送，推送的内容也很有趣，在用户的主动点击下会唤起APP，打开承接页，进而给用户展示个性化的商品。
经过以上5个步骤，至此弱感知链路就完成了使命。
弱感知链路的核心问题在于：
1）推送的消息是否投递给了用户；
2）已投递到的消息用户是否有感知。
这对应推送的两个阶段：
1）推送消息是否已到达设备；
2）用户是否查看推送并点击。
其中：到达设备这个阶段是最基础的，也是本次优化的核心。
我们可以将每一步的消息处理量依次平铺，展开为一张漏斗图，从而直观的查看链路的瓶颈。
漏斗图斜率最大的地方是优化的重点，差异小的地方不需要优化：
通过分析以上漏斗图，弱感知链路的优化重点在三个方面：
1）agoo受理率：是指我们发送推送请到的数量到可以通过agoo（阿里承接离线推送的中台）转发到厂商通道的数量之间的漏斗；
2）厂商受理率：是指agoo中台受理的量到厂商返回成功的量之间的漏斗；
3）Push点击率：也就通过以上通道最终已送到到用户终端的消息，是否最终转化为用户的主动“点击”。
有了优化方向，我们来看看优化手段吧。
跟随推送的视角，顺着链路看一下我们是如何进行优化的。
用户的推送，从Hermes站点搭乘“班车”，驶向下一站：agoo。
这是推送经历的第一站。到站一看，傻眼了，只有不到一半的推送到站下车了。这是咋回事嘞？
这就要先说说agoo了，调用agoo有两种方式：
1）指定设备和客户端，agoo直接将推送投递到相应的设备；
2）指定用户和客户端，agoo根据内部的转换表，找到用户对应的设备，再进行投递。
我们的系统不保存用户的设备信息。因此，是按照用户来调用agoo的。
同时：由于没有用户的设备信息，并不知道用户是iOS客户端还是Android客户端。工程侧不得不向iOS和Android都发送一遍推送。虽然保证了到达，但是，一半的调用都是无效的。
为了解这个问题：我们使用了agoo的设备信息。将用户转换设备这一阶段提前到了调用agoo之前，先明确用户对应的设备，再指定设备调用agoo，从而避免无效调用。
agoo调用方式优化后，立刻剔除了无效调用，agoo受理率有了明显提升。
至此：我们总算能对agoo受理失败的真正原因做一个高大上的分析了。
根据统计：推送被agoo拒绝的主要原因是——用户关闭了通知权限。同时，我们对agoo调用数据的进一步分析发现——有部分用户找不到对应的设备。优化到此，我们猛然发现多了两个问题。
那就继续优化呗：
1）通知体验优化，引导打开通知权限；
2）与agoo共建设备库，解决设备转换失败的问题。
这两个优化方向又是一片新天地，我们择日再聊。
推送到达agoo，分机型搭乘厂商“专列”，驶向下一站：用户设备。
这是推送经历的第二站。出站查票，发现竟然超员了。
于是乎：我们每天有大量推送因为超过厂商设定的限额被拦截。
为什么会这样呢？
实际上：提供推送通道的厂商（没错，各手机厂商的自家推送通道良莠不齐），为了保证用户体验，会对每个应用能够推送的消息总量进行限制。
对于厂商而言，这个限制会根据推送的类型和应用的用户规模设定——推送主要分为产品类的推送和营销类的推送。
厂商推送通道对于不同类型消息的限制是：
1）对于产品类推送，厂商会保证到达；
2）对于营销类推送，厂商会进行额度限制；
3）未标记的推送，默认作为营销类推送对待。
我们刚好没有对推送进行标记，因此触发了厂商的推送限制。
这对我们的用户来说，会带来困扰。闲鱼的交易，很依赖买卖家之间的消息互动。这部分消息是需要确保到达的。
根据主流厂商的接口协议，我们将推送的消息分为以下几类，并进行相应标记：
1）即时通讯消息；
2）订单状态变化；
4）营销消息这几类。
经过这些优化，因为超过厂商限额而被拦截的推送实现了清零。
通过优化agoo受理率、厂商受理率，我们解决了推送到达量的瓶颈。但即使消息被最终送达，用户到底点击了没有？这才是消息推送的根本意义所在。
于是，在日常的开发测试过程中，我们发现了推送的两个体验问题：
2）营销Push也有权限校验，更换用户登陆后无法点击。
针对Push的权限校验功能，闲鱼根据场景做了细分：
1）涉及个人隐私的推送，保持权限校验不变；
2）营销类的推送，放开权限校验。
以上是点击体验的优化，我们还需要考虑用户的点击意愿。
具体的优化手段是：
1）在推送内容上：我们需要优化的是推送的时机和相应的素材；
3）在推送素材上：算法会根据素材的实时点击反馈，对素材做实时赛马。只发用户感兴趣的素材，提高用户点击意愿。
通过以上我们的分析和技术优化手段，整体弱推送链路链路有了不错的提升，离线消息的到达率相对提升了两位数。
本篇主要和大家聊的是只是IM消息系统链路中的一环——弱感知链路的优化，落地到到具体的业务也就是离线消息送达率问题。
整体IM消息系统，还是一个比较复杂的领域。
我们在消息系统的发展过程中，面临着如下问题：
1）如何进行消息的链路追踪；
2）如何保证IM消息的快速到达（见《闲鱼亿级IM消息系统的及时性优化实践》)；
3）如何将消息的玩法和底层能力分离；
4）离线推送中如何通过用户找到对应的设备。
[1]AndroidP正式版即将到来：后台应用保活、消息推送的真正噩梦
[2]一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践
[3]一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等
[4]一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等
[5]从新手到专家：如何设计一套亿级消息量的分布式IM系统
[8]移动端IM中大规模群消息的推送如何保证效率、实时性？
[9]现代IM系统中聊天消息的同步和存储方案探讨
[10]新手入门一篇就够：从零开发移动端IM
[11]移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”
[12]移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结
[13]IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递
[14]IM消息送达保证机制实现(二)：保证离线消息的可靠投递
[15]零基础IM开发入门(一)：什么是IM系统？
[16]零基础IM开发入门(二)：什么是IM系统的实时性？
[17]零基础IM开发入门(三)：什么是IM系统的可靠性？
[18]零基础IM开发入门(四)：什么是IM系统的消息时序一致性？
这个事情需要展开来看
很多大型企业单位为了满足业务系统的使用需要，使用很强劲的服务器主机，以大型机、小型机为主。这些机器都不使用windows系统，所以SQLServer之类的数据库没办法在这种机器上运行。Oracle、DB2、Sybase之类的是主流，这几个数据库有很强大的技术支持团队，也是受到大企业欢迎的原因。
计算机水平国外还是比较高的，所以外国软件公司开发的针对大企业的软件也都要求在这种数据库上运行。
约定俗成，微软的操作系统和数据库由于不能运行在很强劲的主机上，所以只能给中小企业服务。微软系列的还有access数据库，基本上是为单机服务的。
至于MySQL基本上是为网站服务的，主要特点是免费，应用挺多，但是大企业信息化软件很少用，因为没有对应的业务支持人员，到时候出问题，找不到人，就出大事故了。
反过来再看数据库本身，都有参数说明，你仔细看看就知道了。很多小数据库本身底气就不足，并发数量、最大库文件等等参数标得很低，你说大企业动辄几T几P的数据，敢忘这种数据库上放吗？软件公司敢编写用这种数据库的软件吗？
再说说知名度，企业之间都会互相问，要是一个很小很便宜的数据库大家都用，都用得很好，市场占有率极高。自然口碑就好，大家就都用了。微软的sqlsever就是一个例子。从最开始的6.5基本上不能用到sql2000很成功，得到大量企业的认同，到现在出到2008版本，占有率很高了，就是口碑，可是它在大企业中使用不理想，所以还是占有中小企业。
分析这些数据库，应该多方面来看，不能只看参数，只看技术。你都分析好了，发现某个数据库不像大家说的，你能用，可是市场上找不到对应的软件，也没辙，除非你自己编写。