typedef是什么意思中文mysql的存储过程⾯试题，附⾯试答案
⼀、
前些年，互联⽹⾏业⾥对架构师这个岗位的标准还不是很清晰。所以，很多架构师的⼯作往往就是⼀些技术被公司认可的资深⼯程师负责。
彼时，正巧我也是这类⼈员之⼀，故也得到了⼀个从零开始架设⼀套⼴告投放平台的机会。
我很喜欢钻研技术，对这种机会⾃然很看重。
那时候，架构并⽆如今这么复杂，⼀开始就是前⾯搞⼏个 Web 应⽤，后⾯共享个数据库。⼤致像这样：
当然，上⾯的架构其实做了很多简化，省略了很多细节。⽐如，为了提⾼性能做的缓存，为了提⾼吞吐做的负载均衡统统没有在上图给出。因为这些和本章话题⽆关，暂时咱们就忽略这些东西，只看核⼼部分。
这套架构初期运⾏还是没什么问题的，再加上⼀些缓存机制，初期⼀些性能问题都通过调整缓存提升缓存的碰撞率应付了过去。
可是，随着⼴告投放量的增⼤，⼴告的访问量也在暴涨。这些暴涨的访问量引发了性能问题。当时，由于前端有负载均衡，应⽤层倒是没出现什么问题……
问题出在后⾯的数据库上
⼆、
这套架构数据库⽤的是 MySQL，本⾝也只有⼀台主库在对外服务，另外⼀台备库采⽤了 MySQL ⾃⼰的全同步机制做实时备份。
当⼴告访问量暴涨的时候，因为业务需要，很多数据需要在数据库中做实时插⼊，这就导致了⼤量的磁盘 IO 产⽣。这些⼤量的磁盘 IO 造成了数据库本⾝性能的急剧下降。
悲催的是，整套⼴告平台的所有功能⼜都是共享⼀个数据库的，所以随着数据库本⾝的性能下降，平台的所有功能都受到了影响。
由于问题主要在于⼤量⼴告流量的写⼊，所以，靠读写分离的⽅案去缓解问题这条路就⾛不通了。
只好先升级硬件了。在经过了⼏轮硬件升级和数据库调优之后，单数据库再也⽆法⽀撑不断上涨的流量了。没办法，要考虑搞数据库切分了。
那时候，我个⼈是很恐惧数据库切分的。
原因不仅仅在于需要在应⽤层多写很多复杂的逻辑，其根本原因是当时流⾏的 2PC（两阶段提交）⽅案，这个⽅案本⾝能保证在数据库切分的情况下，原来的事务依然保留着⾃⾝的 ACID 性质。即:凌美雪
1. Atomicity（原⼦性），不管事务⾥执⾏多少命令，对外它们都是⼀体的，要么都执⾏，要么都不执⾏。
2. Consistency（⼀致性），正因为事务⾥要么做要么都不做，所以数据库的状态变化只能由事务变更后，才会叫⼀致性状态。
3. Isolation（隔离性），事务⾥做的事⼉事务外⾯谁也看不到，就跟个盒⼦把数据罩起来⼀样，到底中间怎么变化的，事务外⾯的观察
不到。
4. Durability（持久性），事务确认成功了，那这状态就永久不变了。
但也正因为这 4 个特性，2PC 才让我顾虑重重。
顾虑1：⾸先，数据库拆分了，那么根据事务的原⼦性，事务⾃⾝必须是⼀体的，那么事务涉及到的不同的数据库就必须都访问⼀遍，⽽这本⾝就意味着很⾼的通信成本。
再加上，为了保持⼀致性，事务失败后，还必须恢复各个数据库原来的状态，这就必须让已经成功执⾏过本地事务的数据库全部回滚。
⽽稍微懂点数据库的⼈都知道，这个成本有多⼤。
更可怕的是，本⾝事务的隔离性还可能加上锁。⼀旦⼀个热点数据区域被⼤量访问，最差情况就可能出现串⾏访问。⽽这对此套平台，包括我⾃⼰都将是个悲剧。
顾虑2：数据库的拆分会造成整个平台的可⽤性下降。
hbase基本组成>python解析json字符串假设我现在有⼀台数据库，它的可⽤性是 99.9%。如果因为分库，数据库从⼀台变成两台，那么平台的可⽤性就会变成：
平台的可⽤性 = 99.9% * 99.9% = 99.8%
从 99.9% 变成了 99.8%，这意味着可⽤性下降了 0.1%，每个⽉的不可⽤时间会增加 43 分钟之多。
⼀边是硬件升级已经到顶，单机数据库也优化到了极限，再不做数据库拆分，平台可能随时瘫痪。⼀边是没有好的策略，可能拆分数据库后，每个⽉都有宕机的风险，同时性能也可能会出现剧烈的下降。
我被逼⼊了死⾓。
三、
mysql查看所有存储过程
这种痛苦的纠结折磨了我⼤概⼀周，直到我看到了 CAP 定理。当 CAP 定理说分布式系统在分区容错的时候，只能⼀致性和可⽤性⼆选⼀时，我⾼兴的蹦了起来。
原来，可⽤性和⼀致性是不能兼得的。
为何我会那么⾼兴？因为逼我⼊死⾓的可不仅是技术上的问题了，我还承受着来⾃于业务⽅和领导的压⼒。每天⼀上班，我就需要⾯对业务各⽅的抱怨，以及领导⼀轮⼜⼀轮的催促。
有了 CAP 定理的⽀持，我知道我最终是要⾯临选择的。既然在这个世界上做分布式架构的所有⼈都要⾯临选择，那我⼜怎么可能独善其⾝呢？
在对单机数据库引发的各种问题做了⼀次彻底的各种归因以后，我下了决⼼：
⼀定要搞定拆分数据库并给出良好⽅案。
只是，2PC 这个拦路虎，它成为了我的⼤敌。通过 CAP 定理，我⾮常肯定，只要我选了 2PC ⽅案，可⽤性就⼀定会出现严重的问题，这个⽅案也肯定不可能拿出来丢⼈现眼的。
我唯⼀的⽅向就是去牺牲⼀些⼀致性，往可⽤性⽅向⾛。可是，怎么⾛呢？
也许是⽼天眷顾，也许是⼤家都承受着和我⼀样夜不能寐的压⼒，很快，BASE 理论在国内传开了。
BASE 理论让我知道了，这个世上能排到前⼏名的技术⼤公司也⼀样会出问题，也⼀样会对这些问题进⾏妥协。⽽且 BASE 理论的思想让我的思路⼀下⼦就打开了，苦思⽽不得的问题开始有了头绪。
我要开始着⼿制定技术⽅案了。
四、
BASE 思想中的 BA（Basically Available）基本可⽤，是⿎励通过预先的架构设计或者前期规划，尽量在分布式的系统中，把以前可能影响全平台的严重问题，变成只会影响平台中的⼀部分数据或者功能的⾮严重问题。
有了这个思想之后，我就对⼴告平台中的很多重要的数据表进⾏了拆分，并将这些表的数据分散到了不同的数据库中。
⽐如，有个⼴告流量详情表，每当⽤户点击⼴告或者⼴告展⽰出来的时候，为了保证不丢失，这些数据都是实时插⼊到这个表⾥的。
我对这张表是怎么切分的呢？云主机永久免费
当有⼈点击⼴告了，他的点击记录会被传到我的应⽤层，然后我会在应⽤层根据⼴告 ID 做哈希，再根据哈希结果的不同，分别存到不同的数据库中去。
假如这三个数据库中的⼀个出现了问题，则只会有三分之⼀的数据受到影响。这就实现了 BASE 理论中的 BA——基本可⽤了。基本可⽤其实也真的就是表达的这么⼀回事：
通过⼀些架构设计，即使平台中某部分组件出现了问题，也不会导致整个平台不可⽤。
好了，既然采取了数据库拆分的策略，⼜根据 BASE 理论中的 BA 思想拆分了⼀些重要的表，那么，到了现在，可能也⽆从后悔，只能继续沿着 BASE 这条路，⼀条路⾛到⿊了。
五、
接下来，需要着⼿解决性能问题了。2PC ⽅案……算了……它疯狂的⼀致性性格会要了我的狗命的。
那么极端点，我们不搞事务可不可以呢？
还⽤前⾯说的那套⼴告平台举例。
当时，从业务上，要求⼴告的访问数据都要保证及时⼊库不能丢，因为丢了就可能造成计费的损失，⽽这些损失全是钱。所以，每当⽤户点击⼴告或者⼴告展⽰出来的时候，为了保证不丢失，这些数据都是实时⼊库的。
⼜根据业务需求，当⼴告流量⼊库时，还需要往⼴告预算表和媒体流⽔表⾥同时根据这笔流量进⾏记账，以供后续财务计算。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。