稀土掘金官方
获得徽章 14
- #每天一个知识点#
平常你是怎么测试接口的？
通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。
参数组合：现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，
商品id是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。
接口安全：
1、绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？
2、绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功
3、参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。
4、密码安全规则，密码的复杂程度校验
异常验证：
所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。
性能测试
接口并发情况，如上面提到的：一个账号，同时（大于2个请求）对最后一个商品下单，或不同账号，对最后一个商品下单
接口响应时间，响应时间太长了，肯定需要优化，一般都是毫秒级别展开11 - #每天一个知识点#
我们怎么做才能把握flush的时机呢？
Innodb刷脏页控制策略，我们每个电脑主机的io能力是不一样的，你要正确地告诉InnoDB所在主机的IO能力，这样InnoDB才能知道需要全力刷脏页的时候，可以刷多快。
这就要用到innodb_io_capacity这个参数了，它会告诉InnoDB你的磁盘能力，这个值建议设置成磁盘的IOPS，磁盘的IOPS可以通过fio这个工具来测试。
正确地设置innodb_io_capacity参数，可以有效的解决这个问题。
这中间有个有意思的点，刷脏页的时候，旁边如果也是脏页，会一起刷掉的，并且如果周围还有脏页，这个连带责任制会一直蔓延，这种情况其实在机械硬盘时代比较好，一次IO就解决了所有问题，展开评论1 - #每天一个知识点#
索引最基本的东西，N叉树，跳表、LSM我都没讲，同时要创建出好的索引要顾及到很多的方面：
最左前缀匹配原则。这是非常重要、非常重要、非常重要（重要的事情说三遍）的原则，MySQL会一直向右匹配直到遇到范围查询 （>,<,BETWEEN,LIKE）就停止匹配。
尽量选择区分度高的列作为索引，区分度的公式是 COUNT(DISTINCT col)/COUNT(*)。表示字段不重复的比率，比率越大我们扫描的记录数就越少。
索引列不能参与计算，尽量保持列“干净”。比如， FROM_UNIXTIME(create_time)='2016-06-06' 就不能使用索引，原因很简单，B+树中存储的都是数据表中的字段值，但是进行检索时，需要把所有元素都应用函数才能比较，显然这样的代价太大。所以语句要写成 ：create_time=UNIX_TIMESTAMP('2016-06-06')。
尽可能的扩展索引，不要新建立索引。比如表中已经有了a的索引，现在要加（a,b）的索引，那么只需要修改原来的索引即可。
单个多列组合索引和多个单列索引的检索查询效果不同，因为在执行SQL时，MySQL只能使用一个索引，会从多个单列索引中选择一个限制最为严格的索引(经指正，在MySQL5.0以后的版本中，有“合并索引”的策略，翻看了《高性能MySQL 第三版》，书作者认为：还是应该建立起比较好的索引，而不应该依赖于“合并索引”这么一个策略)。
“合并索引”策略简单来讲，就是使用多个单列索引，然后将这些结果用“union或者and”来合并起来展开评论2 - #每天一个知识点#
1.性能测试关注的指标是什么？
从外部看，性能测试主要关注如下三个指标：
吞吐量：每秒钟系统能够处理的请求数、任务数
响应时间：服务处理一个请求或一个任务的耗时
错误率：一批请求中结果出错的请求所占比例
从服务器的角度看，性能测试主要关注CPU、内存、服务器负载、网络、磁盘IO等。
2.性能测试怎么做的？/ 如果你要进行性能测试，你是如何展开操作的？
1.确定关键业务，关键路径；
2.确定测试的关键数据。比如并发量，响应时间，循环次数等；
3.准备测试环境，完成脚本录制或脚本开发；
4.执行测试，观察或监控输出参数，比如吞吐量，响应时间，资源占有率等；
5.对执行结果进行分析，分析性能问题。
3.怎样分析性能测试结果？
1.查看聚合报告和服务器的资源使用图，检查响应时间，事务成功率，CPU，内存和IO使用率是否达到要求，如果出错率达到了总请求的3%，我们会检查是什么原因导致的，修改好后，重新测试；
2.如果出现了性能瓶颈，比如响应时间，或者CPU使用率不达标，我们会从服务器上导出日志，分析是哪个地方导致响应时间过长，如果分析不出来，就叫上开发一起讨论，确定问题后，就提单给代发修复，修复好了就进行回归测试。
4.如何判断网络是否存在瓶颈？
查看在整个性能测试过程中，网络的吞吐量是多少，如果网络的吞吐量占到了服务器的70%以上，我们就认为网络存在瓶颈，通常会增加带宽或者压缩传输数据。
5.如何判断响应时间不达标？
根据性能测试结果先检查看下是否是服务器带宽存在问题，如果带宽存在瓶颈，则会考虑增加带宽或者压缩传输数据，如果带宽没有问题的话，我们会从服务器上导出日志，开发一起讨论分析是哪个地方导致响应时间过长，确定问题后，就提单给开发修复，修复好了就进行回归测试。
6.如何判断CPU使用率不达标？
CPU使用率不达标，我们会从服务器上导出日志，分析是哪个地方导致CPU使用率不达标，如果分析不出来，就叫上开发一起讨论，确定问题后，就提单给开发修复，修复好了就进行回归测试。展开评论1 - #每天一个知识点# http状态码304什么意思？
HTTP状态码304表示客户端已执行get，但文件已更改。一些常见的状态码是：200-服务器成功返回页面，404-请求的页面不存在，503-服务器超时。如果客户机发送了一个条件get请求，并且该请求已被允许，但文档的内容（自上次访问以来或根据请求条件）没有更改，则服务器应返回304状态代码。简单的表达式是客户机已执行get，但文件没有更改。其意义在于，如果一个网站被搜索引擎爬网的次数和频率较多，则更有利于排名，但如果你的网站出现次数过多，则会降低搜索引擎的频率和频率，从而使你的网站排名比别人低一步。
为什么浏览网页出现错误的时候会报404而不是其他数字？404有怎样的含义？
这个问题的简单答案是404代替了其他的出现，这是现代HTTP超文本传输协议的规定。展开评论1 - #每天一个知识点#
你了解MySQL的查询缓存么？
MySQL拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。
大家是不是好奇同一条语句在MySQL执行两次，第一次和后面的时间是不一样的，后者明显快一些，这就是因为缓存的存在。
他跟Redis一样，只要是你之前执行过的语句，都会在内存里面用key-value形式存储着。
查询的时候就会拿着语句先去缓存中查询，如果能够命中就返回缓存的value，如果不命中就执行后面的阶段。
但是我还是不喜欢用缓存，因为缓存弊大于利。
哦？此话怎讲？
缓存的失效很容易，只要对表有任何的更新，这个表的所有查询缓存就会全部被清空，就会出现缓存还没使用，就直接被清空了，或者积累了很多缓存准备用来着，但是一个更新打回原形。
这就导致查询的命中率低的可怕，只有那种只查询不更新的表适用缓存，但是这样的表往往很少存在，一般都是什么配置表之类的。展开评论1 - #每天一个知识点#
什么是主从复制？
主从复制是指将主数据库的DDL和DML操作通过二进制日志传到从数据库上，然后在从数据库上对这些日志进行重新执行，从而使从数据库和主数据库的数据保持一致。
主从复制的原理
MySql主库在事务提交时会把数据变更作为事件记录在二进制日志Binlog中；
主库推送二进制日志文件Binlog中的事件到从库的中继日志Relay Log中，之后从库根据中继日志重做数据变更操作，通过逻辑复制来达到主库和从库的数据一致性；
MySql通过三个线程来完成主从库间的数据复制，其中Binlog Dump线程跑在主库上，I/O线程和SQL线程跑着从库上；
当在从库上启动复制时，首先创建I/O线程连接主库，主库随后创建Binlog Dump线程读取数据库事件并发送给I/O线程，I/O线程获取到事件数据后更新到从库的中继日志Relay Log中去，之后从库上的SQL线程读取中继日志Relay Log中更新的数据库事件并应用。展开评论2 - #每天一个知识点#
Redis如何实现延时队列？
使用sortedset，拿时间戳作为score，消息内容作为key调用zadd来生产消息，消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。
Redis是怎么持久化的？服务主从数据怎么交互的？
RDB做镜像全量持久化，AOF做增量持久化。因为RDB会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要AOF来配合使用。在redis实例重启时，会使用RDB持久化文件重新构建内存，再使用AOF重放近期的操作指令来实现完整恢复重启之前的状态。
这里很好理解，把RDB理解为一整个表全量的数据，AOF理解为每次操作的日志就好了，服务器重启的时候先把表的数据全部搞进去，但是他可能不完整，你再回放一下日志，数据不就完整了嘛。不过Redis本身的机制是 AOF持久化开启且存在AOF文件时，优先加载AOF文件；AOF关闭或者AOF文件不存在时，加载RDB文件；加载AOF/RDB文件城后，Redis启动成功；AOF/RDB文件存在错误时，Redis启动失败并打印错误信息展开评论1 - #每天一个知识点# Pipeline有什么好处，为什么要用pipeline？
可以将多次IO往返的时间缩减为一次，前提是pipeline执行的指令之间没有因果相关性。使用redis-benchmark进行压测的时候可以发现影响redis的QPS峰值的一个重要因素是pipeline批次指令的数目。
Redis的同步机制了解么？
Redis可以使用主从同步，从从同步。第一次同步时，主节点做一次bgsave，并同时将后续修改操作记录到内存buffer，待完成后将RDB文件全量同步到复制节点，复制节点接受完成后将RDB镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。后续的增量数据通过AOF日志同步即可，有点类似数据库的binlog。展开评论1