北京大学图书馆面试准备
岗位:系统开发服务岗
岗位职责:
1.参与图书馆相关业务软件系统开发;
2.从事以下领域的系统研究与开发工作:
1)新一代信息资源管理系统、在线图书馆、融媒体服务系统等研究与开发;
2)文本挖掘、数据挖掘、可视化技术、图像标注等研究与开发;
3.参与数字图书馆相关领域的研究、开发与建设;关注信息技术发展趋势前沿研究与应用;
4.承担图书馆安排的值班;
5.完成交办的其他工作。
招聘基本条件:
-
2022届应届统招统分毕业生;
-
研究生毕业,硕士及以上学位;
-
身心健康,热爱教育管理事业;
-
不超过毕业生在京落户的限制年龄。
基本要求:
1.政治立场坚定,具有良好的职业道德,诚实守信,爱岗敬业,工作细心踏实,服务意识和责任心强;
2.具备较强的学习能力,具备良好的人际沟通能力和团队合作精神,具备良好的心理素质,抗压能力强,勇于担当;能够独立承担图书馆业务相关的项目规划、协调、需求准备、技术准备工作和进行项目开发;
3.具有软件开发能力与开发经验,精通JAVA、Python、C++、PHP、Perl、JavaScript等至少一种开发语言;熟悉软件设计模式、软件开发流程;具有机器学习、人工智能、移动开发、数据挖掘、数据可视化、关联数据、文本分析等相关研究与技术经验者优先考虑;具有解决方案设计、原型设计等经验者优先考虑;
4.具有计算机科学与技术、软件工程、信息与通信工程等相关专业教育背景者优先考虑。
招聘流程:
- 登录北京大学人事招聘系统,填报个人信息,填写完整后提交;
- 通过招聘单位初选的应聘者参加学校统一笔试(考试时间及科目以准考证为准);人数:10人
- 学校统一面试;(10min)人数: 5人
- 面试通过人员,由招聘单位进行考察;
- 中心考察:(开发项目1day、算法编程1h、讲项目设计10min、部门面试30min)人数:3人
- 无领导小组考察:
- 体检;
- 学校审批;
- 公示拟聘用人员。
自我介绍3min(500字左右)
校园经历-实习经历-岗位理解。
各位老师好,我是北京林业大学软件工程专业的-xxx,应聘的是图书馆的应用开发岗。我先简单介绍下我的校园经历和实习经历。
校园(1.5min):本科学的是网络工程,硕士读的是软件工程,算是科班出身,专业基础扎实,开发经验丰富,熟悉python编程语言。在读研期间,由于个人喜欢做志愿服务,就加入了林大校研究生会志愿实践部,和我们的博士生讲师团经常外出到社会做一些志愿教育和宣讲还有校园疫情防控志愿者等工作,这是我觉得在读书期间做的非常有意义的一件事情。同时对校园自媒体比较感兴趣,加上在考研的一年里,研招办公众平台的信息对我有很大的帮助,于是担任了我们研招办的编辑运营,在任职期间也把工作内容和所学专业知识相结合,通过python对新生数据进行挖掘和分析,产出了我们学校两年的新生大数据报告,收获了老师和同学们的好评,也借此获得了一些荣誉奖项。
接下来说一下我的实习经历。
实习(0.5min):在研二的时候有过一段为期一年的互联网公司实习经历,是在滴滴打车做测试开发工程师的工作,偏向于项目管理和软件质量保障的工作。在实习期间,让我对大公司的软件设计模式、开发编码规范、软件项目管理的流程有了很深的理解,也让我对互联网行业有了更清晰的认识。同时在实际工作中也锻炼了我的人际沟通和团队合作的能力。
以上是我的校园经历和实习经历。
最后说一下我对于咱们岗位理解吧。(1min)
在我眼里的图书馆一直是一个非常神圣的地方,如果非要选一个地方能够代表文化的遗产和文明的火种,我想一定非图书馆莫属。跨越千年的文字和典籍,仿佛是在和古人进行接力。而作为中国最高学府的北大,我想我们的图书馆不仅仅是服务于北大的师生,更会参与到全国的图书馆资源共建共享中,乃至服务于整个社会。因此我认为这是一份非常有意义的工作。
先哲功已就,我辈当争先。倘若通过我所做的工作,能够推进北大、乃至中国数字图书馆事业和发展,那一定是我莫大荣幸。
那关于我的个人情况就介绍到这里,谢谢各位老师。
北大图书馆基本知识
宗旨:兼收并蓄 传承文明 创新服务 和谐发展
愿景:建设一个世界一流的,资源丰富、设施先进、高水平、现代化的,以数字化网络化为技术基础的北京大学文献资源保障与服务体系,为学校的教学科研提供文献信息保障,为创建世界一流大学服务。
组织机构:职能部门,业务部门,挂靠机构。我应该是数据资源服务中心。
可以做一个系统,把全国高校图书馆的数字资源接入。实现一个大而全的电子书籍资源池,不,应该是资源海。让每一个人随时随地享受知识的乐趣。
回答提问
为什么报名图书馆的系统开发服务岗?
首先,我对图书馆是有浓厚感情的,上学的时候就经常去图书馆读书学习,尤其是考研的那一年,每天披星戴月的在图书馆之间奔波往返,让我收获了很多的知识与快乐,不过这期间更多的是停留在个人情感层面。
真正令我动容的在疫情的时候,有一则新闻,一个在广东东莞的农民工回乡前,给东莞图书馆写了一封信,他说:“想起这些年在漂泊的17年,来图书馆读书12年,虽万般不舍,然生活所迫!”我看到之后,潸然泪下。也是在这一刻,我体会到了图书馆对于整个社会乃至国家文明的的意义。
因此出于个人情感和社会的责任,我对图书馆的岗位非常有兴趣,如果能用我的个人所学,服务于图书馆用户,能够帮助到别人,这就是我人生中莫大的荣幸了。
图书馆员要有哪些素质?
服务意识:面向读者、满足读者的需求是我们工作的出发点和落脚点。
细心和耐心:管理纷繁复杂的资源,要能耐得住性子,按部就班的把事情做好。
沟通和表达能力:和读者或学校各个部门的人接触比较多。
创新能力:社会的进步和发展,传统的图书馆的数字化转型,提供良好的线上服务。
如何宣传推广在线图书馆?
如果用互联网模式来看的话,推广主要有两种方式,拉新和留存。
可以通过读书打卡,推荐书单,读书分享会,读书日等活动,来进行拉新。
通过提供高质量的资源和服务和个性化的推荐,包括通过公众号或小程序之类的互动方式,来进行留存。当然,我想等真正接触了图书馆的工作,一定能探索出更有意思的推广方式和活动。
如何看待线下图书馆和线上图书馆?
随着信息化的浪潮,传统图书馆也在有了很大的浪潮,有很多声音认为电子书可以代替纸质书,线上网站可以代替图书馆。但我却不这样认为!线上和线下是两种运营模式,不应该是竞争的关系,线下是线上的基础,线上是线下的拓展和补充。两者应该齐头并进,共同将图书馆的职能发扬光大。
你有什么优缺点?
1.我的缺点是很容易受身边的人影响。比如我本科的时候室友都比较贪玩,整天跟着他们打游戏啥的,学习成绩就不太好,还好最后快毕业的时候幡然醒悟,努力学习考上了研究生,也正是有了这段经历,让我深刻的体会到了环境对人的影响。因此无论是工作和学习我都希望能在一个好的团队氛围中。
2.我的缺点就是不知道如何去拒绝别人。同事要我帮忙我会很快答应,尽管自己手头上也有很多需要完成的工作。我会慢慢地学会说“不”,在自己忙的时候尽量告诉同事自己也有很多事情要做,帮不了他们的忙。因为一味地帮助别人是对自己的不负责任另外对同事也不好。
1.我的优点就是比较细心和认真吧,面对重复性的枯燥工作能够不慌不忙的做完,比如之前有帮研招办的老师干活,将几千份报名表和学号对应找出来,还要排好顺序,当时我们几个同学做了正正一天,有几个同学到后来都已经抓狂坐不住了,而我还可以平静的把工作完成。
2.我的性格比较开朗,交流能力比较强,平时也喜欢交朋友,喜欢和同学或者同事交流,与大家都可以相处的很好,通过交流经常能发现很多学习和工作上的不足,这也给了我提升和完善自己的机会。
3.服务意识和责任心比较强,比如我在考研的时候,北林研招办的公众号陪伴了我一年多帮助到了我,那我入学之后就为研招办服务,回馈给其他人。我在研究生会加入了志愿实践部,经常做一些志愿教育和宣讲,这是我认为非常有意义的一件事情。
为什么一直都在实习?
- 我研一的时候因为课还是比较多的,课余时间没有事情做,就通过操作,挤出时间学习。(时间多)
- 我的导师比较放养,没有有价值的项目可以给我做。(没项目)
- 我对互联网行业特别感兴趣,在学校的视野太窄了。(有兴趣)
综上所述,所以我早早的就出来实习了。
有经历过人生至暗时刻或情感波动?
我印象比较深的是刚来北京读研的一段时间,我觉得是我比较down的时刻,也是我成长比较关键的一个节点。
背景:因为本科的时候比较贪玩,也没有一个明确的人生规划,所以就孤注一掷的考研了,妄想通过考验就可以咸鱼翻身。
实际上等真的考上了之后呢,咸鱼翻身还是咸鱼!在考研的时候可以把所有的问题掩盖住,但等考上了之后,所有的问题又暴露了出来,我还是曾经那个少年,除了学历没有一丝改变。那段时间我特别焦虑,不知道考研的意义是什么,不知道以后要做什么,于是开始焦虑,陷入了自我怀疑和自我打气相交替了一个阶段,最后花了一段时间终于考虑了清楚,明确了自己的未来的发展之后,一切都守得云开见月明了。
所以考研对我来说最大的价值,其实并不是提升了学历或者学习到了多少知识,最后重要的是帮我暴露出之前存在的问题,让我找到了未来前进的方向,这对我的人生来说才是最有意义的。
在工作中遇到困难怎么办?
80%先对问题主动思考,带着问题去百度谷歌寻求解决办法,避免请教他人百度就可以解决的肤浅问题。
15%主动尝试,只有在自己主动尝试了不同的问题解法后,“见缝插针” 与 “统一记录”,带着这些尝试后的结果再去请教,别人也会更愿意提供帮助。
在实习中学到了什么?
1.保持终身学习的热情和能力。
2.分清楚事情的轻重缓急,这样才能更游刃有余的在不同工作内容之间进行切换。
3.人际交往非常重要,即使是技术开发岗,其实工作中绝大部分时间都是在和人沟通和协作。
如果录取了有什么职业规划?
正式工作的第1年,成为一名合格的工程师,在必要的辅导或标准流程支持下,能独立负责一个子模块或项目的具体任务,对及时性和准确性负责。在熟悉业务的基础上,了解各职能部门的作用和主要人员,便于工作的交流协作,多向前辈领导们学习。
正式工作的第2-3年,成为独当一面的工程师,独立承担某一模块/专业领域的职责,能够高质量完成工作,能把握一个系统团队的整体实现,能提炼新的方法或方案,或对现有方案提出改进建议。
正式工作的第3-5年,有一定架构能力的工程师,对于一个较为复杂,涉及多个功能点的业务系统,或者技术难度较高的底层系统,能做良好的架构拆解并实现- 对相关的多个业务系统的交互有了解,担任项目负责人,承担评估技术难度与风险、分解目标,推动实施等职责。提升自己的综合管理能力。
不能好高骛远,暂时先做个五年规划,朝着每个阶段的目标去努力。
软件设计模式
设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
1、创建型模式:用来描述 “如何创建对象”,它的主要特点是 “将对象的创建和使用分离”。包括单例、原型、工厂方法、抽象工厂和建造者 5 种模式。
2、结构型模式:用来描述如何将类或对象按照某种布局组成更大的结构。包括代理、适配器、桥接、装饰、外观、享元和组合 7 种模式。
3、行为型模式:用来识别对象之间的常用交流模式以及如何分配职责。包括模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录和解释器 11 种模式。
https://segmentfault.com/a/1190000030850326
软件设计流程
需求分析-详细设计-功能开发-测试-上线。
常用推荐算法
协同过滤:协同过滤推荐的主要思想是,利用已有用户群过去的行为预测当前用户最可能喜欢哪些物品。
分类:基于用户的协同过滤推荐、基于物品的协同过滤推荐和基于模型的协同过滤推荐。
基于用户的协同过滤推荐:1、找到和目标用户兴趣相似的用户集合。2、找到这个集合中的用户喜欢的,且目标用户没有听说过的物品推荐给目标用户。
基于物品的协同过滤推荐:1、计算物品之间的相似度。2、根据物品的相似度和用户的历史行为给用户生成推荐列表。
基于模型的协同过滤推荐:基于样本的用户喜好信息,训练一个推荐模型,然后根据实时的用户喜好的信息进行预测,计算推荐。
基于内容:1、给出物品表示:为每个物品抽取出一些特征来表示此物品;2、学习用户偏好:利用一个用户过去喜欢(及不喜欢)的物品的特征数据,来学习出此用户偏好;3、生成推荐列表:根据候选物品表示和用户偏好,为该用户生成其最可能感兴趣的 n 个物品。
二次笔试面试
一、请在4月13日8:00前完成“简要开发任务“,笔试考察结束后介绍实现思路、完成情况。
二、请在4月13日8:30点前,双机位进入腾讯会议(会议号:419-924-665),进行笔试考察(考察时间1小时),请自备笔纸,答题完毕后拍照发送至本邮箱。
三、9:30-10:00依次进行附件一中“简要开发任务”的展示(每人10分钟),全部应聘者介绍完后,考察小组对应聘者依次进行面试,每人不超过半小时。
.面试当天,请务必携带身份证,以备工作人员核验
简要开发任务:专题文献网页式目录平台
围绕学校师生的专题文献书目检索、浏览与借阅需求,建立“专题文献网页式目录平台”。主要功能点:
1.展示基本书目信息
2.建立层级架构揭示大套书的多层次卷册目录与责任者信息
3.提供子目检索,全文检索功能
提示:
-
大套书举例:四库全书(大体设成部、类、属三级分类。按内容、体例分类,包括4部44类66属)
-
可参考豆瓣、浙大图书馆的古籍特藏平台http://absc.zju.edu.cn/等网站的展示方式。
要求:
-
根据功能需求进行系统结构设计、数据库设计等,并选择合适的前后端框架实现
-
系统设计和实现要体现出自己的技术、设计特长
-
如果时间不够,可以着重介绍设计思路,技术选型和实现方案等。
说在前面
由于时间的关系,本文重点介绍软件开发流程中的需求分析、技术选型、系统架构设计思路、数据库设计方案。需求分析方面,除了对基础的功能做设计之外,还以发展的眼光对未来的功能展望和架构的设计。在实际工作中发现,需求和设计的时间占用软件开发流程60%以上的时间和精力,因此良好的分析和设计是编码实现的基础。
需求分析
基础功能(一期功能)
围绕学校师生的专题文献书目检索、浏览与借阅需求,建立“专题文献网页式目录平台”。主要功能点:
1.展示基本书目信息 实现方式:通过前端http调后端接口查询数据库
2.建立层级架构揭示大套书的多层次卷册目录与责任者信息 实现方式:通过数据库多级索引关联外键
3.提供字母检索,全文检索功能 实现方式:通过es做全文检索
功能展望(后续规划)
1.可以对图书进行评论打分。(类似留言板)
2.可以针对用户个性化的推荐。(特征平台,数据分析和发掘)
3.书籍排行榜。(redis zset)
4.借书到期提醒,无书提前订阅(MQ怎么做?)
5.一起看书功能。(如何保证书籍进度的同步?)
技术选型
以长远的眼光来看,智慧图书馆服务平台应满足易于开发和维护,可以实时的数字化运维监控,性能上满足高并发、高性能、高可用。
本着以上原则技术选型如下:
服务架构:前后端分离的微服务架构(解耦合、高并发、高性能、高可用)
前端框架:vue.js(响应式,组件化开发)
后端框架:golang echo(轻量,高性能,可扩展,开发简单)
数据库:mysql(简单开源好用)
中间件:redis做缓存,es全文检索,日志服务SLS
监控系统:日志服务分析(如阿里云)
高可用:多节点分布式部署(增加容量提升性能、稳定安全)
高并发:全文索引(es分布式,天然支持并发),做缓存(读的时候走redis缓存,写的时候走数据库),MQ(读写操作太多,排队慢慢消费慢慢写),分布式数据库(并发的同时抵抗容灾能力),分库分表。
系统设计
系统概要设计
图1.1智慧图书馆平台展示图

图1.2智慧图书馆平台架构图

基于以上几个目标设计整体架构,整体上框架分为3层:应用表现层、业务逻辑层和数据访问层。
应用表现层:主要封装提供给用户具体应用,在应用层接口测试平台主要封装了6大模块:首页、资源、服务、咨询、专题、关于我们。
业务逻辑层:主要是针对应用表现层做逻辑处理,如资源展示、全文检索、权限管理、图书排行、图书推荐、分类统计等
数据访问层:主要是负责访问数据库表,进行增删改查的操作。
数据库设计
mysql数据库设计
针对图书管理信息系统的需求,通过对图书管理工作过程的内容和数据流程分析,设计如下面所示的9个数据表:包括读者信息表、书籍信息表、管理员信息表、藏书类型表、学科类型表、藏书属性表、预约信息表、借阅信息表和预约规则表。
表1 图书信息表(book)
| 列名 | 类型 | 长度 | 约束 | 备注 |
|---|---|---|---|---|
| bookid | number | 11 | 主键 | 书籍编号 |
| bookname | varchar2 | 20 | 非空 | 书籍名称 |
| author1 | varchar2 | 20 | 非空 | 书籍作者 |
| pubdate | date | 出版日期 | ||
| publish | varchar2 | 30 | 出版社 | |
| photo | varchar2 | 100 | 图片地址 | |
| abstract | varchar2 | 4000 | 内容简介 | |
| Price | number | 7,2 | 非空 | 价格 |
| ISBN | varchar2 | 17 | 非空 | 书籍ISBN码 |
| book_part | number | 11 | 外键 | 藏书部 |
| book_class | number | 11 | 外键 | 藏书类型 |
| book_genus | number | 11 | 外键 | 藏书属性 |
表2 藏书类型表(book_part)
| 列名 | 类型 | 长度 | 约束 | 备注 |
|---|---|---|---|---|
| partid | number | 11 | 主键 | 类型编号 |
| typename | varchar2 | 20 | 非空 | 类型名称 |
| coordinator | varchar2 | 20 | 责任者信息 | |
| demo | varchar2 | 100 | 说明 |
表3 学科类型表(book_class)
| 列名 | 类型 | 长度 | 约束 | 备注 |
|---|---|---|---|---|
| classid | number | 11 | 主键 | 类型编号 |
| classname | varchar2 | 20 | 非空 | 类型名称 |
| coordinator | varchar2 | 20 | 责任者信息 | |
| demo | varchar2 | 100 | 说明 |
表4 藏书属性表(book_genus)
| 列名 | 类型 | 长度 | 约束 | 备注 |
|---|---|---|---|---|
| typeid | number | 11 | 主键 | 类型编号 |
| coordinator | varchar2 | 20 | 责任者信息 | |
| typename | varchar2 | 20 | 非空 | 类型名称 |
| demo | varchar2 | 100 | 说明 |
表5 管理员用户表(admin)
| 列名 | 类型 | 长度 | 约束 | 备注 |
|---|---|---|---|---|
| Id | number | 11 | 主键 | 管理员编号 |
| username | varchar2 | 10 | 非空 | 管理员帐号 |
| password | varchar2 | 11 | 非空 | 帐号密码 |
表6 读者信息表(reader)
| 列名 | 类型 | 长度 | 约束 | 备注 |
|---|---|---|---|---|
| readerid | number | 11 | 主键 | 读者编号 |
| name | varchar2 | 10 | 非空 | 读者姓名 |
| telephone | varchar2 | 15 | 联系电话 | |
| varchar2 | 30 | 邮箱地址 | ||
| dept | varchar2 | 20 | 所在院系 | |
| right | number | 1 | 取值为0或1 | 借阅权限 |
| readertype | number | 11 | 外键 | 读者类型 |
| demo | varchar2 | 1000 | 说明 |
表7 借阅表(borrow)
| 列名 | 类型 | 长度 | 约束 | 备注 |
|---|---|---|---|---|
| readerid | number | 11 | 联合主键,外键 | 读者编号 |
| bookid | number | 11 | 联合主键,外键 | 图书编号 |
| borrowdate | date | 出借日期 | ||
| due | date | 应还日期 |
表8预约表(preconcert)
| 列名 | 类型 | 长度 | 约束 | 备注 |
|---|---|---|---|---|
| readerid | number | 11 | 联合主键,外键 | 读者编号 |
| bookid | number | 11 | 联合主键,外键 | 图书编号 |
| predate | date | 预约日期 |
表9 规则表(rule)
| 列名 | 类型 | 长度 | 约束 | 备注 |
|---|---|---|---|---|
| booktype | number | 11 | 联合主键,外键 | 藏书类型号 |
| readertype | number | 11 | 联合主键,外键 | 读者类型号 |
| days | number | 5 | 非空 | 期限(天) |
| num | number | 5 | 非空 | 册数(本) |
| renew | number | 5 | 非空 | 续借次数(次) |
| overtime | number | 5,2 | 非空 | 逾期处罚(元/册/天) |
redis数据库设计
redis主要是做缓存,数据加载到redis中用来读,数据库做持久化用来写。目的是防止流量过大,限流。
技术重难点
1.实现图书数据库的管理,大套书的多层次管理。确保mysql的高可用
2.字母检索和全文检索功能。**确保ES的高可用**
确保mysql的高可用
如何实现大套书的多层次卷册数据库管理?
四库全书(大体设成部、类、属三级分类。按内容、体例分类,包括4部44类66属)
通过对图书信息表(book),增设外键做映射,把 藏书类型表(book_part)、学科类型表(book_class)、藏书属性表(book_genus)关联起来实现多层次的卷册数据库管理。
如何确保mysql的高可用?
主从复制和读写分离:为了数据的安全性和减轻主数据库的压力。
主从复制:是一种数据备份的方案。是使用两个或两个以上相同的数据库,将一个数据库当做主数据库,而另一个数据库当做从数据库。在主数据库中进行相应操作时,从数据库记录下所有主数据库的操作,使其二者一模一样。
主要涉及三个线程: binlog 线程、I/O 线程和 SQL 线程。
- binlog 线程 : 负责将主服务器上的数据更改写入二进制日志中。
- I/O 线程 : 负责从主服务器上读取二进制日志,并写入从服务器的中继日志中。
- SQL 线程 : 负责读取中继日志并重放其中的 SQL 语句。
读写分离:是一种让数据库更稳定的的使用数据库的方法。是在有从数据库的情况下使用,当主数据库进行对数据的增删改也就是写操作时,将查询的任务交给从数据库。
读写分离主要是为了提高性能,因为。
- 主从服务器负责各自的读和写,极大程度缓解了锁的争用;
- 从服务器可以使用 MyISAM,提升查询性能以及节约系统开销;
- 增加冗余,提高可用性。
读写分离常用代理方式来实现,代理服务器接收应用层传来的读写请求,然后决定转发到哪个服务器。
如何保证redis缓存和mysql双写一致性?
高并发的业务场景,数据库往往是最薄弱的环节。因此用redis做缓存,削减对数据库的请求。但是当数据发生变化不管是先写MySQL数据库,再删除Redis缓存;还是先删除缓存,再写库,都有可能出现数据不一致的情况。
整体架构:1.命中缓存从缓存加载数据,直接返回。2.没有命中缓存,从数据库加载加载数据3.加载到的数据写入缓存
解决方案一:延时双删。
- 先删除缓存;
- 再写数据库;
- 休眠XX毫秒;(根据具体的业务时间来定,还要考虑redis和数据库主从同步)
- 再次删除缓存。
设置缓存过期时间是关键点
1、从理论上来说,给缓存设置过期时间,是保证最终一致性的解决方案 2、所有的写操作以数据库为准,只要到达缓存过期时间,缓存删除 3、如果后面还有读请求的话,就会从数据库中读取新值然后回填缓存
结合双删策略+缓存超时设置,这样最差的情况就是:
1、在缓存过期时间内发生数据存在不一致 2、同时又增加了写请求的耗时。
为什么要双删呢?
因为第一次删除的是还没更新前的数据,第二次删除则是因为读取的并发性导致的缓存重新写入数据出现的垃圾数据。
如果删缓存失败了怎么办?还是会出现缓存和数据库不一致的情况么?
引入中间件消息队列来进行重试机制。 步骤: 1、业务代码去更新数据库 2、数据库的操作进行记录日志。 3、订阅程序提取出所需要的数据以及key 4、获得该信息尝试删除缓存,发现删除失败的时候,发送消息到消息队列 5、继续重试删除缓存的操作,直到删除缓存成功。
其实这个方法与分布式事务的处理方式,就是保证数据的最终一致性,而在分布式事务中,则称之为这种为最大努力通知。那么最大努力通知又是什么样的流程呢?
1、业务方把通知发送给 MQ 2、接收通知方监听 MQ 3、接收通知方接收消息,业务处理完成回应ack 4、接收通知方若没有回应ack则MQ会重复通知,MQ 按照间隔时间从短到长的方式逐步拉大通知间隔,直到达到通知要求的时间上限,比如24小时之后不再进行通知。 5、接收通知方可通过消息校对接口来校对消息的一致性
总结: 而为什么叫最大努力通知呢,实际上也很容易理解,他并没有从本质上解决问题,只是把问题数目从100 变成了 10 ,毕竟有些内容第一次没处理,第二次就可能会被处理掉。也就是说降低了这种有问题情况的发生,毕竟保证的都是最终一致性。
解决方案二:异步更新缓存(基于订阅binlog的同步机制)
MySQL binlog增量订阅消费+消息队列+增量数据更新到redis
- 读Redis:热数据基本都在Redis
- 写MySQL:增删改都是操作MySQL
- 更新Redis数据:MySQ的数据操作binlog,来更新到Redis
1)数据操作主要分为两大块:
- 一个是全量(将全部数据一次写入到redis)
- 一个是增量(实时更新)这里说的是增量,指的是mysql的update、insert、delate变更数据。
2)读取binlog后分析 ,利用消息队列,推送更新各台的redis缓存数据。
这样一旦MySQL中产生了新的写入、更新、删除等操作,就可以把binlog相关的消息推送至Redis,Redis再根据binlog中的记录,对Redis进行更新。
其实这种机制,很类似MySQL的主从备份机制,因为MySQL的主备也是通过binlog来实现的数据一致性。
这里可以结合使用canal(阿里的一款开源框架),通过该框架可以对MySQL的binlog进行订阅,而canal正是模仿了mysql的slave数据库的备份请求,使得Redis的数据更新达到了相同的效果。
当然,这里的消息推送工具你也可以采用别的第三方:kafka、rabbitMQ等来实现推送更新Redis。
在高并发应用场景下,如果是对数据一致性要求高的情况下,要定位好导致数据和缓存不一致的原因。
https://blog.csdn.net/JineD/article/details/120898975
数据量过大怎么处理?
千万级别的数据量mysql是没问题的。超过千万级别的可以按照分类分库分表,如:古今中外。水平拆分和垂直拆分。
图片音视频类的资源如何存储?
mysql也能存,但不建议,影响性能。最好还是oss,
为什么要使用Elasticsearch
因为我们图书的数据将来会非常多,所以采用以往的模糊查询,模糊查询前置配置,会放弃索引,导致书籍查询是全表扫面,在百万级别的数据库中,效率非常低下,而我们使用ES做一个全文索引,我们将经常查询的商品的某些字段,比如说书名,描述、价格还有id这些字段我们放入我们索引库里,可以提高查询速度。
ES过程
https://www.cnblogs.com/QLCZ/p/15044301.html
lucene数据存储
Elasticsearch如何实现全文检索?
ES使用的是倒排索引。
正排索引:通过id(Key)查字词(value)。 如msyql 关系型数据库。当查询比如 name 的时候,需要使用 like,如果数据量大,查询时间久。
倒排索引:通过字或词(value)为关键字查id(key)。就能快速找到内容。由于词汇数量是相对有限且固定的,所以效率并不会由于日后关键词的增长而受到很大的影响。
倒排索引的核心就是分词。
es有很多内置的分词器,适用于处理英文。
为什么在默认分词器下,不能查找到词汇呢?
英文一个词汇就是一个单词,汉字需要两个字才可以表示词汇。因此需要引用如IK分词器,原理就是自己维护了中文的词汇文本。。
3000w的字,用多少存储。
1M=1024 × 1024/2=524288(个汉字)
Elasticsearch如何保证高可用?
调优从设计、写入、查询等方面都可以优化,设计:冷热分离。定期 force_merge 加 shrink 压缩操作,节省存储空间和检索效率。
性能与容量之间的矛盾由来已久,计算机的多级存储体系就是其中一个经典的例子,同样的问题在Elasticsearch中也存在。
应用场景:在成本有限的前提下,让客户关注的实时数据和历史数据硬件隔离,最大化解决客户反应的响应时间慢的问题。
数据量大到TB级别,在查询和写入的频率高,容易出现性能问题。因此es存储要采用冷热数据读写分离。热用的ssd,冷的用机械磁盘。
冷数据索引:查询频率低,基本无写入,一般为当天或最近2天以前的数据索引
热数据索引:查询频率高,写入压力大,一般为当天数据索引
冷热分离架构是Elasticsearch的经典架构之一,使用该架构用户可以在保证热数据良好读写性能的同时,仍可以存储海量的数据,极大地丰富了ES的应用场景,解决了用户的成本问题。
https://www.cnblogs.com/caoweixiong/p/11988457.html
https://cloud.tencent.com/developer/article/1521098?from=article.detail.1771336
es 写入数据、查询数据的工作原理?
es 写数据过程
- 客户端选择一个 node 发送请求过去,这个 node 就是
coordinating node(协调节点)。 coordinating node对 document 进行路由,将请求转发给对应的 node(有 primary shard)。[路由的算法是?]- 实际的 node 上的
primary shard处理请求,然后将数据同步到replica node。 coordinating node如果发现primary node和所有replica node都搞定之后,就返回响应结果给客户端。
es 读数据过程
可以通过 doc id 来查询,会根据 doc id 进行 hash,判断出来当时把 doc id 分配到了哪个 shard 上面去,从那个 shard 去查询。
- 客户端发送请求到任意一个 node,成为
coordinate node。 coordinate node对doc id进行哈希路由,将请求转发到对应的 node,此时会使用round-robin随机轮询算法,在primary shard以及其所有 replica 中随机选择一个,让读请求负载均衡。- 接收请求的 node 返回 document 给
coordinate node。 coordinate node返回 document 给客户端。
写请求是写入 primary shard,然后同步给所有的 replica shard;读请求可以从 primary shard 或 replica shard 读取,采用的是随机轮询算法。
在 Elasticsearch 中,是怎么根据一个词找到对应的倒排索引的?
(1)Lucene的索引过程,就是按照全文检索的基本过程,将倒排表写成此文件格式的过程。
(2)Lucene的搜索过程,就是按照此文件格式将索引进去的信息读出来,然后计算每篇文档打分(score)的过程。
底层的 lucene ?
Lucene 是有索引和搜索的两个过程,包含索引创建,索引,搜索三个要点。可以基于这个脉络展开一些。
简单来说,lucene 就是一个 jar 包,里面包含了封装好的各种建立倒排索引的算法代码。我们用 Java 开发的时候,引入 lucene jar,然后基于 lucene 的 api 去开发就可以了。
通过 lucene,我们可以将已有的数据建立索引,lucene 会在本地磁盘上面,给我们组织索引的数据结构。
一些思考
Soa面向服务架构思想
Soa:把系统按照实际业务,拆分成刚刚好大小的、合适的、独立部署的模块,每个模块之间相互独立。
rpc是soa落地的一种手段。
而SOAP、REST、RPC就是根据这种设计模式构建出来的规范,其中SOAP通俗理解就是http+xml的形式,REST就是http+json的形式,RPC是基于socket的形式。上文提到的CXF就是典型的SOAP/REST框架,thrift就是典型的RPC框架,而SpringCloud就是遵守REST规范的生态系统。
RPC (Remote Procedure Call)远程过程调用是一个计算机通信协议。我们一般的程序调用是本地程序内部的调用,RPC允许你像调用本地函数一样去调用另一个程序的函数,这中间会涉及网络通信和进程间通信,但你无需知道实现细节,RPC框架为你屏蔽了底层实现。RPC是一种服务器-客户端(Client/Server)模式,经典实现是一个通过发送请求-接受回应进行信息交互的系统。
日志服务SLS
日志服务SLS是云原生观测与分析平台,为Log、Metric、Trace等数据提供大规模、低成本、实时的平台化服务。日志服务一站式提供数据采集、加工、查询与分析、可视化、告警、消费与投递等功能,全面提升您在研发、运维、运营、安全等场景的数字化能力。
微服务架构
就是一些协同工作小而自治的服务。单个应用程序被划分成各种小的、互相连接的微服务,一个微服务完成一个比较单一的功能,相互之间保持独立和解耦合,这就是微服务架构。目的是有效的拆分应用,实现敏捷开发和部署。
传统开发的缺点:
1、效率低:开发都在同一个项目改代码,相互等待,冲突不断
2、维护难:代码功功能耦合在一起,新人不知道何从下手
3、不灵活:构建时间长,任何小修改都要重构整个项目,耗时
4、稳定性差:一个微小的问题,都可能导致整个应用挂掉
5、扩展性不够:无法满足高并发下的业务需求
微服务的优点:
技术异构性:不同的服务可以选择不同的技术。
隔离性:各个服务独立自治,互不影响,提高可用性。
可扩展性:升级和改动只是小的模块
简化部署:部署快,出问题影响小,回滚快。
容易优化:重构代码容易,好的代码是重构出来的,影响可控。
微服务缺点:
服务注册和发现:众多互相调用的服务地址不容易管理。常用的做法是在变更时上报给服务注册中心,进行注册,服务方订阅变更通知。
服务监控:需要完备的监控体系,拓扑关系,监控,日志,调用追踪,报警通知等
服务容错:需要引入熔断、隔离、限流、降级、超时机制等保证服务的可用性
服务安全:对敏感服务采用安全鉴权机制等。
服务治理:为了解决上述被污染的问题,可能要引用服务治理。
为什么要多级缓存
传统的缓存策略一般是请求到达服务器后,先查询Redis,如果未命中则查询数据库,但请求经过服务器处理,服务器的性能会成为系统瓶颈,redis缓存过期失效时,容易发生雪崩和穿透,会对数据库产生冲击。
多级缓存就是充分利用请求处理的每个环节,分别添加缓存,减轻服务器压力,提升服务性能。
- 第一级缓存:用户通过手机访问浏览器得到渲染。 浏览器缓存。
-
第二级缓存:Nginx本地缓存。浏览器本地缓存未成功,请求Nginx服务器.Ngin之前是用来做请求代理。在这里形成第二级缓存,称为Nginx本地缓存。 也可以做业务的编写。那么将数据缓存到nging本地,用户请求来了,如果有直接返回,不用到达Tomcat
-
第三级缓存:redis缓存。
- 第四级缓存:服务器进程缓存。
- 第五级缓存:最后到达数据库缓存。
智慧图书馆服务平台的未来
纸电一体:能够准确揭示所有馆藏资源。
数据打通:能够分析图书馆内部产生的所有数据。
云部署:一般采用SaaS云(Software-as-a-Service软件即服务),降低维护成本,保证服务性能。
开放的API和高可扩展性。
参考资料:
首都图书馆网站
豆瓣网站
浙江图书馆网站
浙大古籍特藏资源平台
https://www.libstar.net/html/techFeature/techFeature.html
https://blog.csdn.net/qq_40625778/article/details/106759953
无领导小组讨论
先自己分析,讨论之前建议用共享文档。
如果需要投票可以采用腾讯会议。