平日的工作中，我们经常会跟业务同学讨论新的需求，每次需求讨论的时候，你是否有一套属于自己的方法论？也就是你需要业务提供什么信息，你需要告知业务什么信息。关于这一点，我进行了总结，希望对大家有所帮助。
这里我把它分为业务方 To DBA和DBA To 业务方，不局限于任何一种数据库，mysql、redis、Pika、MongoDB、TiDB等常见数据库都适用，下面我们展开看看。
01
业务 To DBA
这块的内容比较重要，也比较多，我列举的是我日常比较关注的几个点，可能不全面，不过你可以跟你自己的想法碰撞一下，查漏补缺，可能你就能总结出来一套你自己的方法论了。
行了，话不多说。开始：
1、申请的数据库用途，隶属于哪一个产品线。
用途是最基本的信息，能够帮助我们确定保存的数据的价值密度以及重要程度。
2、业务方存储的数据内容，预估的数据量，最大并发写入量，每日、每月、每年数据增长量。
评估数据的具体内容、容量、并发量、增长量，可以让我们很快的决定到底使用哪一种数据库，例如数据量很小，需要并发量很大，就需要考虑缓存（Redis、MC），如果数据量很大，需要的并发量又一般，就可以考虑使用存储（MySQL、MongoDB）。
3、具体的数据库版本、数据库架构。
选定数据库之后，需要确定数据库版本，根据并发量和容量，确定高可用架构
4、业务的读写高峰时间段。
这个信息有利于我们确定实例数量，用来抗住业务峰值流量。
5、访问方式，例如长链接，短连接，对数据库进行读写操作的时候，如果失败了，是否有重试机制，如果重试也失败了，是否会丢数据，有没有相应的补偿机制。
这里还是需要引导业务同学增加执行失败的SQL日志，便于极端情况下数据库服务出现问题的时候，后期用来补录数据。
6、如果极端情况下数据库出现问题，影响面有多大。业务上是否有降级措施或者快速恢复服务的办法。
虽然数据库本身能够保障高可用，但是这块内容很重要，很多时候，DBA侧都需要跟业务侧配合，才能将故障场景下的损失降到最小
7、业务对一致性和可用性的要求，以及需要DBA提供的SLA。
一致性和可用性要求，可以帮助我们在数据库服务出现问题的时候，最大可能地减小业务损失。SLA则可以保证我们提供的数据库服务质量是符合业务要求的。
8、是否需要额外的监控指标推送。
目前数据库服务的提供，都需要配套的监控措施，从而让业务对数据库服务的基本运行状态进行了解。
02
DBA To 业务
通常情况下，DBA对业务同学提的要求，大多数都写在数据库应用开发规范里面，可以根据开发规范对业务进行叮嘱，除了开发规范之外，还有几点需要注意：
1、为了避免数据库过载，通常会在数据库上面配置过载保护，常见的过载保护有：超时请求kill机制、空闲连接kill机制。
在业务使用数据库服务的时候，需要告知业务过载保护机制，避免出现业务连接因请求超时或者空闲时间过长被kill之后，一头雾水的情况。
2、如果业务使用长链接连接域名的方法访问数据库，在故障切换过后，有可能出现域名解析成功，但是业务连接没有重连，导致写入旧主库的情况，这样也会造成数据丢失，而且补录的时候会非常麻烦，因此请务必在数据库服务切换过后，重启应用服务。
