2019.5.20中午
一通电话,小哥哥电话打来
记录下问题把
1自我介绍
2介绍下你的项目的闪光点把,我说了中心账户系统,他问我做这个的目的是为了什么?
其实做这个没什么目的,因为要对接ssp,ssp不是我们的,但是我们有几个子系统是要对接ssp的,因此拿着人家的接口文档,
在搭出一个中间的服务啦,不想总是去看ssp,直接调用我中心账户的,是不更好一些,同时我作为数据透传方,我必须要保证自己的安全啊,
3索引的优缺点?所以底层的数据结构?b树和b+树有区别嘛?选哪一个?
索引的优点
1.通过创建唯一索引,可以保证数据库每一行数据的唯一性2.可以大大提高查询速度3.可以加速表与表的连接4.可以显著的减少查询中分组和排序的时间。
索引的缺点
1.创建索引和维护索引需要时间,而且数据量越大时间越长2.创建索引需要占据磁盘的空间,如果有大量的索引,可能比数据文件更快达到最大文件尺寸3.当对表中的数据进行增加,修改,删除的时候,索引也要同时进行维护,降低了数据的维护速度
4问了快排,让说一下思想?稳定排序和非稳定排序?快排属于哪一个?
设要排序的数组是A[0]……A[N-1],首先任意选取一个数据(通常选用数组的第一个数)作为关键数据,然后将所有比它小的数都放到它左边,所有比它大的数都放到它右边,这个过程称为一趟快速排序。值得注意的是,快速排序不是一种稳定的排序算法,也就是说,多个相同的值的相对位置也许会在算法结束时产生变动。
一趟快速排序的算法是:
1)设置两个变量i、j,排序开始的时候:i=0,j=N-1;
2)以第一个数组元素作为关键数据,赋值给key,即key=A[0];
3)从j开始向前搜索,即由后开始向前搜索(j--),找到第一个小于key的值A[j],将A[j]和A[i]的值交换;
4)从i开始向后搜索,即由前开始向后搜索(i++),找到第一个大于key的A[i],将A[i]和A[j]的值交换;
5)重复第3、4步,直到i=j; (3,4步中,没找到符合条件的值,即3中A[j]不小于key,4中A[i]不大于key的时候改变j、i的值,使得j=j-1,i=i+1,直至找到为止。找到符合条件的值,进行交换的时候i, j指针位置不变。另外,i==j这一过程一定正好是i+或j-完成的时候,此时令循环结束)。
5用过redis?redis数据结构说下?,说一下hash的过期策略,如果都没到期怎么删除?
配置一下redis呗
【过期策略+内存淘汰机制】
名词解释
过期策略:即redis针对过期的key使用的清除策略,策略为,定期删除+惰性删除
内存淘汰机制:即内存占用达到内存限制设定值时触发的redis的淘汰策略来删除键
【过期策略】
定期删除,redis默认每隔100ms检查,是否有过期的key,有过期key则删除。需要说明的是,redis不是每隔100ms将所有的key检查一次,而是随机抽取进行检查(如果每隔100ms,全部key进行检查,redis岂不是卡死)。因此,如果只采用定期删除策略,会导致很多key到时间没有删除。
惰性删除,也就是说在你获取某个key的时候,redis会检查一下,这个key如果设置了过期时间那么是否过期了?如果过期了此时就会删除。
过期策略存在的问题,由于redis定期删除是随机抽取检查,不可能扫描清除掉所有过期的key并删除,然后一些key由于未被请求,惰性删除也未触发。这样redis的内存占用会越来越高。此时就需要内存淘汰机制
【内存淘汰机制】
redis配置文件中可以使用maxmemory
策略有如下几种:(LRU的意思是:Least Recently Used最近最少使用的,LFU的意思是:Least Frequently Used最不常用的)
volatile-lru -> Evict using approximated LRU among the keys with an expire set.
在带有过期时间的键中选择最近最少使用的。(推荐)
allkeys-lru -> Evict any key using approximated LRU.
在所有的键中选择最近最少使用的。(不区分是否携带过期时间)(一般推荐)
volatile-lfu -> Evict using approximated LFU among the keys with an expire set.
在带有过期时间的键中选择最不常用的。
allkeys-lfu -> Evict any key using approximated LFU.
在所有的键中选择最不常用的。(不区分是否携带过期时间)
volatile-random -> Remove a random key among the ones with an expire set.
在带有过期时间的键中随机选择。
allkeys-random -> Remove a random key, any key.
在所有的键中随机选择。
volatile-ttl -> Remove the key with the nearest expire time (minor TTL)
在带有过期时间的键中选择过期时间最小的。
noeviction -> Don't evict anything, just return an error on write operations.
不要删除任何东西,只是在写操作上返回一个错误。默认。
6你有什么问题?我问了支付宝是怎么保证他的服务稳定的?我还问了转账怎么保证的?
小哥哥跟我说了一堆,包括架构重构,一些中间件redis,mongodb,还说了实时监控,报警之类的,分布式等等,
怕是凉了啊。。。。。。。。。。。。。。。。。
【我自己说下保证服务稳定的思路吧】
dns:一域名映射多ip,每个ip上都是一个nginx,每个nginx都反向代理,
公司的技术总监最近出了一道架构方面的问题让我们同组的开发人员设计,题目是这样的:有个签到功能,需要记录每个⽤户每年每⼀天的签到情况。假设⽤户量在千万,甚⾄亿级,该如何设计。
思考这个问题后,我给出的设计方案如下:
第一层:通过DNS,同一个域名绑定多个IP,在DNS上进行负载均衡。
第二层:中央Nginx集群,通过DNS负载均衡后,通过nginx二次负载均衡(Nginx的配置需要根据服务器配置调整,比如连接数,进程数等);
第三层:web层,将应用部署在多个节点上。
第四层:消息引擎层,将上层数据写入消息引擎中,consumer端将数据异步入库,建议使用kafka,吞吐量大。
第五层:数据库层,数据量庞大,传统的关系型数据库已经不太适用,即使通过水平分库分表,按日期或按userid分库,也很难解决存储和跨多库的查询问题。可以考虑使用MongoDB或大数据技术(HDFS和HBASE)来存储签到数据。
不知道合不合理,但总的设计理念是:负载均衡+异步。同时也要在Nginx和Linux内核方面进行优化,以抵抗更大的压
7中间件你都用过什么?
mq,redis,负载均衡中间件nginx,数据中间件mqI(消息中间件),redis,应用服务器中间件tomcat