正是有了这样简单易用的用户体验，使得精卫平台在应用的接入效率和用户满意度上都有非常不错的表现。
（4）平台管控和统计
在精卫的平台中，每天都运行着上千亿次的数据同步和复制任务，必然需要对这些任务的执行有一个清晰的管控，甚至可以从中找出对业务数据变化的趋势。实现的方法是定时轮询Zookeeper集群中对应任务的节点进行监控，如图5-17所示。目前提供以下三个方面监控：
心跳监控。
延迟堆积监控。
任务状态、数据监控（TPS、异常）等。
图5-17 精卫平台提供的数据同步监控
采用类似精卫这样的平台实现数据异构索引的好处是，不需要在各个前端应用层的代码中去实现，只需统一通过精卫平台实现。有了这样专业的平台来实现数据同步的效率、服务高可用性、任务管控、统计等，能提供更好的服务。但设计这样的平台确实需要掌握数据库相关知识，以及任务调度、平台管控等技术，甚至需要在各种复杂场景中逐步打磨和完善技术。所以如果有些企业还没有这样数据同步的专业平台，通常会建议采用通过在应用层实现数据的异构索引，具体实现方式在6.3节中重点阐述。
5.将多条件频繁查询引入搜索引擎平台
采用数据异构索引的方式在实战中基本能解决和避免90%以上的跨join或全表扫描的情况，是在分布式数据场景下，提升数据库服务性能和处理吞吐能力的最有效技术手段。但在某些场景下，比如淘宝商品的搜索（如图5-18）和高级搜索（如图5-19），因为商品搜索几乎是访问淘宝用户都会进行的操作，所以调用非常频繁，如果采用SQL语句的方式在商品数据库进行全表扫描的操作，则必然对数据库的整体性能和数据库连接资源带来巨大的压力。
图5-18 淘宝网商品全文搜索
图5-19 淘宝网商品高级搜索
所以面对此类场景，我们不建议采用数据库的方式提供这样的搜索服务，而是采用专业的搜索引擎平台来行使这样的职能，实现的架构如图5-20所示。
图5-20 全文搜索实现示意图
阿里巴巴有自身的主搜索平台，该平台承载了淘宝、天猫、一淘、1688、神马搜索等搜索业务，其核心功能跟业界开源工具，如Iucene、Solr、ElasticSearch等搜索引擎类似，但在数据同步（从数据库到搜索引擎）、索引创建算法、查询执行计划、排序算法等方面针对商品搜索这样的场景做了相应的调整和功能增强。该搜索平台目前已经以阿里云上OpenSearch产品的形态，给有此类搜索需求的客户提供强大的搜索服务，更多关于该平台详细的资料可访问开放搜索服务的官方网站：
https://www.aliyun.com/product/opensearch。
6.简单就是美
在真实的世界中，选择的困难往往是因为充满着各种诱惑，选择A方案，有这些好处；而选择B方案，也会有另外一些好处。
如果在“尽量减小事务边界”与“数据尽可能平均拆分”两个原则间发生了冲突，那么请选择“数据尽可能平均拆分”作为优先考虑原则，因为事务边界的问题相对来说更好解决，无论是做全表扫描或做异构索引复制都是可以解决的。而写入或单机容量如果出现不均衡，那么处理起来难度就比较大。
尽管复杂的切分规则或数据的异构索引能够给系统的性能和扩展性带来显著的收益，但其后面所带来的系统运维复杂度上升也是不能忽视的一个结果。
如果为每一个存在跨join或全表扫描的场景都采用数据异构索引的方式，整个数据库出现大量数据冗余，数据一致性的保障也会带来挑战，同时数据库间的业务逻辑关系也变得非常复杂，给数据库运维带来困难和风险，从而对数据库运维人员的要求和依赖会非常高，所以从系统风险的角度考虑，以82法则，在实际中，我们仅针对那些在80%情况下访问的那20%的场景进行如数据异构索引这样的处理，达到这类场景的性能最优化，而对其他80%偶尔出现跨库join、全表扫描的场景，采用最为简单直接的方式往往是就最有效的方式。
