某大公司一面二面

1.redis数据类型及使用场景
string 
String是最常用的一种数据类型,普通的key/value存储都可以归为此类,value其实不仅是String,也可以是数字:比如想知道什么时候封锁一个IP地址(访问超过几次)。INCRBY命令让这些变得很容易,通过原子递增保持计数。
Hash
常用命令:hget,hset,hgetall 等。
应用场景:
Key仍然是用户ID,value是一个Map,这个Map的key是成员的属性名,value是属性值,这样对数据的修改和存取都可以直接通过其内部Map的Key(Redis里称内部Map的key为field), 也就是通过 key(用户ID) + field(属性标签) 操作对应属性数据了,既不需要重复存储数据,也不会带来序列化和并发修改控制的问题。很好的解决了问题。
List
常用命令:lpush,rpush,lpop,rpop,lrange,BLPOP(阻塞版)等。
应用场景:Redis list的应用场景非常多,也是Redis最重要的数据结构之一。我们可以轻松地实现最新消息排行等功能。Lists的另一个应用就是消息队列,可以利用Lists的PUSH操作,将任务存在Lists中,然后工作线程再用POP操作将任务取出进行执行。
实现方式: Redis list的实现为一个双向链表,即可以支持反向查找和遍历,更方便操作,不过带来了部分额外的内存开销,Redis内部的很多实现,包括发送缓冲队列等也都是用的这个数据结构。
Set
常用命令: sadd,srem,spop,sdiff ,smembers,sunion 等。
应用场景: Redis set对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择,并且set提供了判断某个成员是否在一个set集合内的重要接口,这个也是list所不能提供的。
 比如在微博应用中,每个人的好友存在一个集合(set)中,这样求两个人的共同好友的操作,可能就只需要用求交集命令即可。Redis还为集合提供了求交集、并集、差集等操作,可以非常方便的实
实现方式: set 的内部实现是一个 value永远为null的HashMap,实际就是通过计算hash的方式来快速排重的,这也是set能提供判断一个成员是否在集合内的原因。
Sorted set(zset)
常用命令: zadd,zrange,zrem,zcard等
使用场景:以某个条件为权重,比如按顶的次数排序. ZREVRANGE命令可以用来按照得分来获取前100名的用户,ZRANK可以用来获取用户排名,非常直接而且操作容易。
Redis sorted set的使用场景与set类似,区别是set不是自动有序的,而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序,并且是插入有序的,即自动排序。
比如:twitter 的public timeline可以以发表时间作为score来存储,这样获取时就是自动按时间排好序的。
 比如:全班同学成绩的SortedSets,value可以是同学的学号,而score就可以是其考试得分,这样数据插入集合的,就已经进行了天然的排序。
另外还可以用Sorted Sets来做带权重的队列,比如普通消息的score为1,重要消息的score为2,然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。
需要精准设定过期时间的应用
 比如你可以把上面说到的sorted set的score值设置成过期时间的时间戳,那么就可以简单地通过过期时间排序,定时清除过期数据了,不仅是清除Redis中的过期数据,你完全可以把Redis里这个过期时间当成是对数据库中数据的索引,用Redis来找出哪些数据需要过期删除,然后再精准地从数据库中删除相应的记录。
实现方式:
    Redis sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序,HashMap里放的是成员到score的映射,而跳跃表里存放的是所有的成员,排序依据是HashMap里存的score,使用跳跃表的结构可以获得比较高的查找效率,并且在实现上比较简单。
消息订阅Pub/Sub
 Pub/Sub 从字面上理解就是发布(Publish)与订阅(Subscribe),在Redis中,你可以设定对某一个key值进行消息发布及消息订阅,
    当一个key值上进行了消息发布后,所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统,比如普通的即时聊天,群聊等功能。
Transactions
谁说NoSQL都不支持事务,虽然Redis的Transactions提供的并不是严格的ACID的事务(比如一串用EXEC提交执行的命令,在执行中服务器宕机,那么会有一部分命令执行了,剩下的没执行),但是这个Transactions还是提供了基本的命令打包执行的功能(在服务器不出问题的情况下,可以保证一连串的命令是顺序在一起执行的,中间有会有其它客户端命令插进来执行)。 Redis还提供了一个Watch功能,你可以对一个key进行Watch,然后再执行Transactions,在这过程中,如果这个Watched的值进行了修改,那么这个Transactions会发现并拒绝执行。
2.mysql优化方面,索引的建立以及explain调优等等
	选取最适用的字段属性
	使用连接(JOIN)来代替子查询(Sub-Queries)
	使用联合(UNION)来代替手动创建的临时表
	事务
	锁优化
	使用外键
	使用索引(短索引,排序使用复合索引)
	优化的查询语句(慢查询)
3.优化访问速度,从客户端开始所有的过程
	前端(懒执行,有交互才执行 图片尺寸的控制和懒加载更懒的执行,刷新页面才执行)
	开启opencache 缓存
	页面静态化
	cdn加速(图片文件视频,视频直播流移动应用加速
	缓存请求内容(php文件缓存或者redis/menchache)
	异步返回
4.session跨域怎么解决
原因:
	http是无状态的, 也就是说服务器不知道谁访问过他,但是有时间,又需要我们去保留这个状态比如说用户的登录信息,如果每次访问都要登录
	session 的缺点也很明显,session 是存在服务器的内存中的,如果 session 过多会影响服务器的性能。因为 session 只在一台服务器里,当有多台服务器的时候,访问别的服务器肯定会失败。
解决方案:
•	Session Sticky(是指让同一客户端的请求,落在同一台服务器上,因为不会落在别的服务器上,所以自然就不会出现跨域问题。用户的请求落在那一台服务器上都是由用户来决定的,可能会造成单点压力,并且如果一台服务器出问题,可能会造成一片区域的人无法访问)
•	Session复制(是指服务器之间互相同步session信息,也就是说每台服务器上都保存着所有的session信息。这样做的缺点也是非常明显的。上文提到过,session 是存在内存中的,会严重影响服务器性能,当然,你也可以把他存在数据库中,但是这会大大影响响应速度。还有一个缺点就是,当访问量过大时,由于相互同步的问题,会造成大量的网络开销)
•	Session集中存储(是指把 session 集中存储在一个第三方的服务器中,可以是 Redis,可以是数据库或是其他什么东西。当需要访问的时候,都去这个服务器去查。这样做也有不小的缺点,首先是单点问题,如果这个服务器宕机,那么所有的服务器都是不可用的,所以这里必须做集群,会浪费服务器资源。还有一点是,每次验证都需要来这个服务器来查,会凭白增加一次网络开销,降低访问速度)
•	Cookie(状态信息不再保存在服务端,而是保存在客户端,客户端每次访问服务器的时候,把这个信息带给服务器。但是 Cookie 也有不少问题,最被人关注的就是安全问题,因为信息是保存在客户端的,就比较容易盗取、篡改,当然这些安全问题都是有解决方案的,这不是限制 Cookie 的主要原因,真正限制 Cookie 的原因是很多设备不支持Cookie)
•	Token(Token 也是由客户端来维持状态的,信息存储在客户端内,具有平台无关性。Token实质上是服务端给客户端的一个字符串,上面包含着一些验证信息,相当于一个身份令牌,你拿着这个令牌就能得到他的服务。相比较于 Cookie,Token 更加的灵活,可以在任何地方生成,基于 Token 的权限系统是非常容易实现的)

5.高并发问题,库存为负,秒杀等等
	mysql排它锁(排他锁又称为写锁,简称X锁,顾名思义,排他锁就是不能与其他所并存,如一个事务获取了一个数据行的排他锁,其他事务就不能再获取该行的其他锁,包括共享锁和排他锁,但是获取排他锁的事务是可以对数据就行读取和修改。就是类似于我在执行update操作的时候,这一行是一个事务(默认加了排他锁)。这一行不能被任何其他线程修改和读写)
	使用版本号, update了,同时更新了版本号
	redis的单线程预减库存每一个用户线程进来,key值就减1,等减到0的时候,全部拒绝剩下的请求

6.excel导出大量数据怎么处理(内存不够,响应超时方面)
	上传时处理:在执行页面添加:set_time_limit(0);
	内存溢出:在执行页面添加:ini_set("memory_limit", "1024M");
	设置PHPExcel单元格缓存(元格缓存是将所需PHPExcel内存单元格对象缓存到磁盘、memcache、MemoryGZip等,这样读取上会更耗时,但可以降低内存的消耗。)
7.识别文件格式,修改了后缀怎么识别
	storage 得到文件数组,然后再遍历进行过滤筛选,这种对于文件较多不是很方便,而且比较慢
	使用php自带的glob函数,进行直接筛选;
$files=glob($path.$match);
foreach($files as $file){
$list[]=substr($file,strrpos($file,"/")+1);
}  
	使用symfony的Finder包,这个包Laravel本来就自带了,所以直接上方法:
	图片使用getimagesize获取信息
8.缓存穿透,缓存雪崩问题
 缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者,攻击会导致数据库压力过大。
解决: 接口层增加校验,如用户鉴权校验,id做基础校验,id<=0的直接拦截;
从缓存取不到的数据,在数据库中也没有取到,这时也可以将key-value对写为key-null,缓存有效时间可以设置短点,如30秒(设置太长会导致正常情况也没法使用)。这样可以防止攻击用户反复用同一个id暴力攻击
缓存雪崩
 描述:
 缓存雪崩是指缓存中数据大批量到过期时间,而查询数据量巨大,引起数据库压力过大甚至down机。和缓存击穿不同的是,缓存击穿指并发查同一条数据,缓存雪崩是不同数据都过期了,很多数据都查不到从而查数据库。
 解决方案:
缓存数据的过期时间设置随机,防止同一时间大量数据过期现象发生。
如果缓存数据库是分布式部署,将热点数据均匀分布在不同搞得缓存数据库中。
设置热点数据永远不过期。

9.cookie和session的区别,从存储方法,存储容量,存储数据类型都方面分析区别
存放位置:
	cookie存放在客户端的临时文件里。创建与服务端,保存在浏览器,可以有多个浏览器共享
	session存在服务器的内存中,一个session域对象为一个用户浏览器服务。
安全性:
	cookie是以文明方式存放在客户端,安全较差,可以通过md5再存放、
	session是存放在服务器端的内存中,所以安全性好
网络传输量:
	cookie会传递信息给服务端
	session的属性值不会给客户端
生命周期:
	cookie是累计时间
	session是间隔时间
session失效情况:
	关闭服务器
	重装 web应用
	设置了国企时间,时间到了
	服务器错误也会让session失效。
使用原则:
	session会占用服务器的内存
从范围来看
	session为单用户独享
	cookie为多个用户浏览器共享
保存信息的方法有两种:
	保存在文件里面
	保存在数据库里面
10.composer的工作原理
Packagist 是 Composer 的默认的开发包仓库。你可以将自己的安装包提交到 packagist,将来你在自己的 VCS (源码管理软件,比如 Github)仓库中新建了 tag 或更新了代码,packagist 都会自动构建一个新的开发包。这就是 packagist 目前的运作方式,将来 packagist 将允许直接上传开发包,发布自己的包。
11.php设计模式,列举一个说明工作原理
	单例模式: 例模式确保某一个类只有一个实例,并且对外提供这个全局实例的访问入口
	工厂模式:定义一个抽象工厂,其定义了产品的生产接口,但不负责具体的产品,将生产任务交给不同的派生类工厂。这样不用通过指定类型来创建对象了。
	责任链模式: 职责链上的处理者负责处理请求,客户只需要将请求发送到职责链上即可,无须关心请求的处理细节和请求的传递,所以职责链将请求的发送者和请求的处理者解耦了。
	建造者模式:建造者模式使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。
	原型模式是用于创建重复的对象,同时又能保证性能。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。
	适配器模式: 这种模式涉及到一个单一的类,该类负责加入独立的或不兼容的接口功能。举个真实的例子,读卡器是作为内存卡和笔记本之间的适配器。您将内存卡插入读卡器,再将读卡器插入笔记本,这样就可以通过笔记本来读取内存卡。
12.mysql性能优化,索引,表设计,分库分表等方面
mysql性能优化:连接次数,分析查询语句
表设计: 
	适度冗余, 让query尽量减少join 虽然optimizer会对query进行一定的优化,但有时候遇见复杂的join,优化效果并不令人满意,再加上本来join的性能...
	大字段垂直分拆 所谓的大字段,没有一个很严格的标准,常用的是如果一个字段的大小占...
	大表水平分拆 举例说明:在一个论坛系统里,管理员经常会发一些帖子,这些帖子要求在...
	选择合适的数据类型 要选择合适的数据类型必须要先了解不同数据类型间的差异
分库分表: 
	大数据量并且访问频繁的表,将其分为若干个表。
	利用merge存储引擎来实现分表
13.消息队列在项目中的应用,redis队列或activemq等应用

14.nosql在项目中的应用,redis和mongodb或membercache的区别,分别在什么场景下使用
性能
三者的性能都比较高,总的来讲:Memcache和Redis差不多,要高于MongoDB。
便利性
memcache数据结构单一。
redis丰富一些,数据操作方面,redis更好一些,较少的网络IO次数。
mongodb支持丰富的数据表达,索引,最类似关系型数据库,支持的查询语言非常丰富。
存储空间
redis在2.0版本后增加了自己的VM特性,突破物理内存的限制;可以对key value设置过期时间(类似memcache)。
memcache可以修改最大可用内存,采用LRU算法。
mongoDB适合大数据量的存储,依赖操作系统VM做内存管理,吃内存也比较厉害,服务不要和别的服务在一起。
可用性
redis,依赖客户端来实现分布式读写;主从复制时,每次从节点重新连接主节点都要依赖整个快照,无增量复制,因性能和效率问题,所以单点问题比较复杂;不支持自动sharding,需要依赖程序设定一致hash 机制。一种替代方案是,不用redis本身的复制机制,采用自己做主动复制(多份存储),或者改成增量复制的方式(需要自己实现),一致性问题和性能的权衡。
Memcache本身没有数据冗余机制,也没必要;对于故障预防,采用依赖成熟的hash或者环状的算法,解决单点故障引起的抖动问题。
mongoDB支持master-slave,replicaset(内部采用paxos选举算法,自动故障恢复),auto sharding机制,对客户端屏蔽了故障转移和切分机制。
可靠性
redis支持(快照、AOF):依赖快照进行持久化,aof增强了可靠性的同时,对性能有所影响。
memcache不支持,通常用在做缓存,提升性能。
MongoDB从1.8版本开始采用binlog方式支持持久化的可靠性。
一致性
Memcache 在并发场景下,用cas保证一致性。
redis事务支持比较弱,只能保证事务中的每个操作连续执行。
mongoDB不支持事务。
数据分析
mongoDB内置了数据分析的功能(mapreduce),其他两者不支持。
应用场景
redis:数据量较小的更性能操作和运算上。
memcache:用于在动态系统中减少数据库负载,提升性能;做缓存,提高性能(适合读多写少,对于数据量比较大,可以采用sharding)。
MongoDB:主要解决海量数据的访问效率问题。

15.讲解最近的一个项目,自己负责的模块的业务流程和技术点

大海技术博客
请先登录后发表评论
  • latest comments
  • 总共0条评论