一、简述一下MongoDB的应用场景 mongodb 支持副本集、索引、自动分片，可以保证较高的性能和可用性。 更高的写入负载 默认情况下，MongoDB 更侧重高数据写入性能，而非事务安全，MongoDB 很适合业务系统中有大量 “低价值” 数据的场景。但是应当避免在高事务安全性的系统中使用 MongoDB，除非能从架构设计上保证事务安全。 高可用性 MongoDB 的复副集 (Master-Slave) 配置非常简洁方便，此外，MongoDB 可以快速响应的处理单节点故障，自动、安全地完成故障转移。这些特性使得 MongoDB 能在一个相对不稳定（如云主机）的环境中，保持高可用性。 数据量很大或者未来会变得很大 依赖数据库 (MySQL) 自身的特性，完成数据的扩展是较困难的事，在 MySQL 中，当一个单达表到 5-10GB 时会出现明显的性能降级，此时需要通过数据的水平和垂直拆分、库的拆分完成扩展，使用 MySQL 通常需要借助驱动层或代理层完成这类需求。而 MongoDB 内建了多种数据分片的特性，可以很好地适应大数据量的需求。 基于位置的数据查询 MongoDB 支持二维空间索引，因此可以快速及精确地从指定位置获取数据。 表结构不明确 在一些传统 RDBMS 中，增加一个字段会锁住整个数据库 / 表，或者在执行一个重负载的请求时会明显造成其它请求的性能降级。通常发生在数据表大于 1G 的时候（当大于 1TB 时更甚）。 因 MongoDB 是文档型数据库，为非结构货的文档增加一个新字段是很快速的操作，并且不会影响到已有数据。另外一个好处当业务数据发生变化时，是将不再需要由 DBA 修改表结构。 二、数据库设计经验，为什么进行分表？分库？一般多少数据量开始分表？分库？分库分表的目的？ 1、为什么要分表 当一张表的数据达到几百万时，你查询一次所花的时间会变多，如果有联合查询的话，有可能会死在那儿了。分表的目的就在于此，减小数据库的负担，缩短查询时间。日常开发中我们经常会遇到大表的情况，所谓的大表是指存储了百万级乃至千万级条记录的表。这样的表过于庞大，导致数据库在查询和插入的时候耗时太长，性能低下，如果涉及联合查询的情况，性能会更加糟糕。 分表和表分区的目的就是减少数据库的负担，提高数据库的效率，通常点来讲就是提高表的增删改查效率。数据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO 等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。 2、分表的方案 做 mysql 集群，有人会问 mysql 集群，根分表有什么关系吗？虽然它不是实际意义上的分表，但是它启到了分表的作用，做集群的意义是什么呢？为一个数据库减轻负担，说白了就是减少 sql 排队队列中的 sql 的数量，举个例子：有 10 个 sql 请求，如果放在一个数据库服务器的排队队列中，他要等很长时间，如果把这 10 个 sql 请求，分配到 5 个数据库服务器的排队队列中，一个数据库服务器的队列中只有 2 个，这样等待时间是不是大大的缩短了呢？ linux mysql proxy 的安装，配置，以及读写分离 mysql replication 互为主从的安装及配置，以及数据同步 优点：扩展性好，没有多个分表后的复杂操作（php 代码） 缺点：单个表的数据量还是没有变，一次操作所花的时间还是那么多，硬件开销大。 三、简述一下数据库主从复制，读写分离 * 什么是主从复制 主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库； * 主从复制的原理： 1.数据库有个bin-log二进制文件，记录了所有的sql语句。 2.只需要把主数据库的bin-log文件中的sql语句复制。 3.让其从数据的relay-log重做日志文件中再执行一次这些sql语句即可。 * 主从复制的作用 1.做数据的热备份，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。 2.架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问频率，提高单机的I/O性能 3.主从复制是读写分离的基础，使数据库能制成更大 的并发。例如子报表中，由于部署报表的sql语句十分慢，导致锁表，影响前台的服务。如果前台服务使用master，报表使用slave，那么报表sql将不会造成前台所，保证了前台的访问速度。 * 主从复制的几种方式： 1.同步复制：所谓的同步复制，意思是master的变化，必须等待slave-1,slave-2,…,slave-n完成后才能返回。 2.异步复制：如同AJAX请求一样。master只需要完成自己的数据库操作即可。至于slaves是否收到二进制日志，是否完成操作，不用关心。MYSQL的默认设置。 3.半同步复制：master只保证slaves中的一个操作成功，就返回，其他slave不管。 这个功能，是由google为MYSQL引入的。 * 关于读写分离 在完成主从复制时，由于slave是需要同步master的。所以对于insert/delete/update这些更新数据库的操作，应该在master中完成。而select的查询操作，则落下到slave中。
一、写一段代码判断单向链表中有没有形成环，如果形成环，请找出环的入口处，即 P 点 二、从扑克牌中随机抽出 5 张牌，判断是不是一个顺子，即这5张牌是连续的 这个问题有个关键点，扑克牌，1-13 不能再多了。这就很简单了。用PHP来做，定义一个数组分别存着1到13, 拿出一个，置空一个，最后看下这五个置空的 是不是连续的。这种情况不考虑抽出的顺序。 三、说一下 PHP 的（内存）垃圾回收机制 每一个变量对应一个 zval 数据结构，在该结构内还有一个 val 结构体，该结构体内有一个引用计数（php7 而言，对于 php5，这个引用计数是保存在 zval 结构中的），标识该对象的引用数，当对象的引用计数为 0 时代表这个对象可被回收。 对象的 refcount 减少的时机：修改变量、函数返回（释放局部变量）、unset 变量 对于数组和对象而言，可能存在变量中的成员引用变量本身的情况，也就是循环引用，这样会造成这个变量永远不会被内存回收，而成为垃圾。 PHP 里对于这种情况给出了垃圾回收机制：如果数组、对象的引用计数减少而且不为零，则认为他们可能是垃圾，把他们放到垃圾收集器里。等垃圾收集器到了一定的数量之后，进行垃圾处理：对所有可能的垃圾 refcount 减 1，如果为 1，说明是垃圾，则进行内存回收；如果不为 1，说明还有其他变量在使用，refcount 重新加 1；这种对象复用以及垃圾回收机制在其他语言中也有体现：redis 中也使用了引用计数表示每个对象的引用数量。 四、简述一下PHP短信验证码如何防刷？ 1、时间限制：60 秒后才能再次发送 从发送验证码开始，前端（客户端）会进行一个 60 秒的倒数，在这一分钟之内，用户是无法提交多次发送信息的请求的。这种方法虽然使用得比较普遍，但是却不是非常有用，技术稍微好点的人完全可以绕过这个限制，直接发送短信验证码。 2、手机号限制：同一个手机号，24 小时之内不能够超过 5 条 对使用同一个手机号码进行注册或者其他发送短信验证码的操作的时候，系统可以对这个手机号码进行限制，例如，24 小时只能发送 5 条短信验证码，超出限制则进行报错（如：系统繁忙，请稍后再试）。然而，这也只能够避免人工手动刷短信而已，对于批量使用不同手机号码来刷短信的机器，这种方法也是无可奈何的。 3、短信验证码限制：30 分钟之内发送同一个验证码 网上还有一种方法说：30 分钟之内，所有的请求，所发送的短信验证码都是同一个验证码。第一次请求短信接口，然后缓存短信验证码结果，30 分钟之内再次请求，则直接返回缓存的内容。对于这种方式，不是很清楚短信接口商会不会对发送缓存信息收取费用，如果有兴趣可以了解了解。 4、前后端校验：提交 Token 参数校验 这种方式比较少人说到，个人觉得可以这种方法值得一试。前端（客户端）在请求发送短信的时候，同时向服务端提交一个 Token 参数，服务端对这个 Token 参数进行校验，校验通过之后，再向请求发送短信的接口向用户手机发送短信。 5、唯一性限制：微信产品，限制同一个微信 ID 用户的请求数量 如果是微信的产品的话，可以通过微信 ID 来进行识别，然后对同一个微信 ID 的用户限制，24 小时之内最多只能够发送一定量的短信。 6、产品流程限制：分步骤进行 例如注册的短信验证码使用场景，我们将注册的步骤分成 2 步，用户在输入手机号码并设置了密码之后，下一步才进入验证码的验证步骤。 7、图形验证码限制：图形验证通过后再请求接口 用户输入图形验证码并通过之后，再请求短信接口获取验证码。为了有更好的用户体验，也可以设计成：一开始不需要输入图形验证码，在操作达到一定量之后，才需要输入图形验证码。具体情况请根据具体场景来进行设计。 8、IP 及 Cookie 限制：限制相同的 IP/Cookie 信息最大数量 使用 Cookie 或者 IP，能够简单识别同一个用户，然后对相同的用户进行限制（如：24 小时内最多只能够发送 20 条短信）。然而，Cookie 能够清理、IP 能够模拟，而且 IP 还会出现局域网相同 IP 的情况，因此，在使用此方法的时候，应该根据具体情况来思考。 9、短信预警机制，做好出问题之后的防护 以上的方法并不一定能够完全杜绝短信被刷，因此，我们也应该做好短信的预警机制，即当短信的使用量达到一定量之后，向管理员发送预警信息，管理员可以立刻对短信的接口情况进行监控和防护。 五、mySQL 里有 2000w 数据，redis 中只存 20w 的数据，如何保证 redis 中的数据都是热点数据 相关知识：redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略（回收策略）。redis 提供 6 种数据淘汰策略： volatile-lru：从已设置过期时间的数据集（server.db [i].expires）中挑选最近最少使用的数据淘汰 volatile-ttl：从已设置过期时间的数据集（server.db [i].expires）中挑选将要过期的数据淘汰 volatile-random：从已设置过期时间的数据集（server.db [i].expires）中任意选择数据淘汰 allkeys-lru：从数据集（server.db [i].dict）中挑选最近最少使用的数据淘汰 allkeys-random：从数据集（server.db [i].dict）中任意选择数据淘汰 no-enviction（驱逐）：禁止驱逐数据
