• 关于

    数据系统干啥用的

    的搜索结果

问题

云服务器 ECS咋用啊,本人小白一只

乱世小泥鳅 2019-12-01 21:43:53 3604 浏览量 回答数 5

问题

大牛们好小白啥也不懂求问怎么用ECS搭建DZ和维护

新手啊啊啊 2019-12-01 20:57:00 4029 浏览量 回答数 8

问题

如何设计一个高并发系统?【Java问答学堂】45期

剑曼红尘 2020-06-28 20:53:14 10 浏览量 回答数 1

Quick BI 数据可视化分析平台

2020年入选全球Gartner ABI魔力象限,为中国首个且唯一入选BI产品

回答

取出之后要遍历对一些数据进行操作. 读取的时候,就取一些数据.###### 内存溢出跟放到list里还是放到别的数据结构里没有关系,本身数据量过大。 参数设置增加内存,或者不全部取出,改为sql直接操作数据库。###### 不能每次取100条么###### 为啥要取一次性取那么多数据  ###### 分页吧,骚年###### 啥数据类型?字符串,二进制?###### 看你后续要做什么,如果只是转换的操作,增加字段,直接在数据库用 sql 干; 如果后续再其他系统加工;可以放在文件,kafka,redis 里面,主要是看你后续的业务。######要一次性取完么? 可不可以使用数组取,先有一个流,然后边取边往文件夹里面放?求大神指点######不能分批读么?每条数据处理有先后关系么,没有的话完全可以一次只查询少量数据吧?###### 直接sql语句筛选啊,拿出来筛选效率太低了

kun坤 2020-06-06 23:06:45 0 浏览量 回答数 0

回答

Re为啥低配的没有windosws系统选择阿 因为512M内存运行WINDOWS太吃力了,开机就占用近400M了,如果你再装个MYSQL,MSSQL之类的,无访问量都会慢,相对于LINUX系统来说,WIN系统本身就占用比较多的资源,所以只建议1G内存或以上的配置使用。 ------------------------- Re为啥低配的没有windosws系统选择阿 “能用”与“够用”是两个概念,好不好?你512M内存,其实跑到600M占用也没事的,照样也是能用,但是效率呢?执行速度呢?硬盘IO呢?有没有考虑过这些经!! ------------------------- 回6楼alilab的帖子 这个问题见仁见智了我觉得,肯定要看放在上面的站点访问量与资源占用量,有些站占用个200-300M内存很正常,如果只有512M内存,那超出只能用硬盘当缓存,而阿里目前的硬盘IO问题还没有得到解决,这种情况肯定会影响到网站的访问速度,当然了,如果你说我就一个站,并且还是静态的,也没有数据库,也没有什么人访问,那当然512M内存足够了,如果是这样干吗买云主机,一个小小的虚拟主机完全可以够用了。

dns2008 2019-12-02 00:38:35 0 浏览量 回答数 0

回答

首先您要弄清楚PGXS是干啥用的?PGXS在手册的35.16. Extension Building Infrastructure有详细的介绍.简单来说如果你写了一个PostgreSQL的Extension, 在发布的时候给它写一个轻便的build系统也是一件比较麻烦的事情.PGXS提供了一套简单的Extension的build框架. 因此只需要按照PGXS提供的模板写一个简单的makefile就可以在一个已经安装好的PostgreSQL Server上编译你的Extension了. 需要注意的是PGXS并不是一个可以适用所有PostgreSQL相关软件的build框架, 复杂的软件还是需要自己写build系统的.查看模板文件的位置通过pg_config --pgxs可以查看模板文件的位置:pg_config --pgxs /opt/pgsql/lib/pgxs/src/makefiles/pgxs.mkpgxs.mk的具体内容具体内容可以查看官方文档,阿里云数据库专家德哥写过一篇文档,可供参考,链接如下:http://blog.163.com/digoal@126/blog/static/16387704020122208374396/

卓刀 2019-12-01 23:13:39 0 浏览量 回答数 0

问题

云主机为啥这么久都不能更换节点?

imnpc 2019-12-01 21:23:16 6912 浏览量 回答数 9

回答

为何要用Node.js?现在是寻找如何替代Node.js吗? ###### 后台还行. 前台你换成这俩完全就是没事儿找事儿. 用个html + jstemplate什么的就行了. ###### 不要犹豫了,jfinal走起 ######nginx+JFinal+ Tomcat + EhCache + Redis,如果访问量还是撑不住,再加 CDN 和 varnish。前端用 js 做对搜索引擎收录不利######回复 @西夏一品堂 : OSChina 日访问IP超过50万,两台服务器,用的就是EhCache+Redis,可看看这里:http://www.oschina.net/p/j2cache,视频介绍:http://v.youku.com/v_show/id_XNzAzMTY5MjUy.html######回复 @西夏一品堂 : EhCache 是本 JVM 去内存取数据,速度非常快,而 Redis 需要序列化与反序列化,还需要进程之间传递数据,如果redis部署在其它服务器,还需要走网络传输######有redis了,还用EhCache干啥?######前端用 js 做对搜索引擎收录不利######加 varnish就必须要考虑页面的动静分离,以及缓存的清除、过期、更新。另外你的系统是什么类型的呢,是网站呢,还是业务系统。memorycache和redis都可以做缓存,为什么要两个同时用呢?两种分别用来做什么?

kun坤 2020-05-29 23:05:09 0 浏览量 回答数 0

回答

面试官心理分析 其实面试官主要是想看看: 第一,你知不知道你们系统里为什么要用消息队列这个东西? 不少候选人,说自己项目里用了 Redis、MQ,但是其实他并不知道自己为什么要用这个东西。其实说白了,就是为了用而用,或者是别人设计的架构,他从头到尾都没思考过。 没有对自己的架构问过为什么的人,一定是平时没有思考的人,面试官对这类候选人印象通常很不好。因为面试官担心你进了团队之后只会木头木脑的干呆活儿,不会自己思考。 第二,你既然用了消息队列这个东西,你知不知道用了有什么好处&坏处? 你要是没考虑过这个,那你盲目弄个 MQ 进系统里,后面出了问题你是不是就自己溜了给公司留坑?你要是没考虑过引入一个技术可能存在的弊端和风险,面试官把这类候选人招进来了,基本可能就是挖坑型选手。就怕你干 1 年挖一堆坑,自己跳槽了,给公司留下无穷后患。 第三,既然你用了 MQ,可能是某一种 MQ,那么你当时做没做过调研? 你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ,比如 Kafka,甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。每一个 MQ 没有绝对的好坏,但是就是看用在哪个场景可以扬长避短,利用其优势,规避其劣势。 如果是一个不考虑技术选型的候选人招进了团队,leader 交给他一个任务,去设计个什么系统,他在里面用一些技术,可能都没考虑过选型,最后选的技术可能并不一定合适,一样是留坑。 面试题剖析 为什么使用消息队列 其实就是问问你消息队列都有哪些使用场景,然后你项目里具体是什么场景,说说你在这个场景里用消息队列是什么? 面试官问你这个问题,期望的一个回答是说,你们公司有个什么业务场景,这个业务场景有个什么技术挑战,如果不用 MQ 可能会很麻烦,但是你现在用了 MQ 之后带给了你很多的好处。 先说一下消息队列常见的使用场景吧,其实场景有很多,但是比较核心的有 3 个:解耦、异步、削峰。 解耦 看这么个场景。A 系统发送数据到 BCD 三个系统,通过接口调用发送。如果 E 系统也要这个数据呢?那如果 C 系统现在不需要了呢?A 系统负责人几乎崩溃...... 在这个场景中,A 系统跟其它各种乱七八糟的系统严重耦合,A 系统产生一条比较关键的数据,很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办?要不要重发,要不要把消息存起来?头发都白了啊! 如果使用 MQ,A 系统产生一条数据,发送到 MQ 里面去,哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据,直接从 MQ 里消费即可;如果某个系统不需要这条数据了,就取消对 MQ 消息的消费即可。这样下来,A 系统压根儿不需要去考虑要给谁发送数据,不需要维护这个代码,也不需要考虑人家是否调用成功、失败超时等情况。 总结:通过一个 MQ,Pub/Sub 发布订阅消息这么一个模型,A 系统就跟其它系统彻底解耦了。 面试技巧:你需要去考虑一下你负责的系统中是否有类似的场景,就是一个系统或者一个模块,调用了多个系统或者模块,互相之间的调用很复杂,维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的,如果用 MQ 给它异步化解耦,也是可以的,你就需要去考虑在你的项目里,是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西,用 MQ 作解耦。 异步 再来看一个场景,A 系统接收一个请求,需要在自己本地写库,还需要在 BCD 三个系统写库,自己本地写库要 3ms,BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms,接近 1s,用户感觉搞个什么东西,慢死了慢死了。用户通过浏览器发起请求,等待个 1s,这几乎是不可接受的。 一般互联网类的企业,对于用户直接的操作,一般要求是每个请求都必须在 200 ms 以内完成,对用户几乎是无感知的。 如果使用 MQ,那么 A 系统连续发送 3 条消息到 MQ 队列中,假如耗时 5ms,A 系统从接受一个请求到返回响应给用户,总时长是 3 + 5 = 8ms,对于用户而言,其实感觉上就是点个按钮,8ms 以后就直接返回了,爽!网站做得真好,真快! 削峰 每天 0:00 到 12:00,A 系统风平浪静,每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ,每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的,大量的请求涌入 MySQL,每秒钟对 MySQL 执行约 5k 条 SQL。 一般的 MySQL,扛到每秒 2k 个请求就差不多了,如果每秒请求到 5k 的话,可能就直接把 MySQL 给打死了,导致系统崩溃,用户也就没法再使用系统了。 但是高峰期一过,到了下午的时候,就成了低峰期,可能也就 1w 的用户同时在网站上操作,每秒中的请求数量可能也就 50 个请求,对整个系统几乎没有任何的压力。 如果使用 MQ,每秒 5k 个请求写入 MQ,A 系统每秒钟最多处理 2k 个请求,因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求,每秒钟就拉取 2k 个请求,不要超过自己每秒能处理的最大请求数量就 ok,这样下来,哪怕是高峰期的时候,A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来,就 2k 个请求出去,结果就导致在中午高峰期(1 个小时),可能有几十万甚至几百万的请求积压在 MQ 中。 这个短暂的高峰期积压是 ok 的,因为高峰期过了之后,每秒钟就 50 个请求进 MQ,但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说,只要高峰期一过,A 系统就会快速将积压的消息给解决掉。 消息队列有什么优缺点 优点上面已经说了,就是在特殊场景下有其对应的好处,解耦、异步、削峰。 缺点有以下几个: 系统可用性降低 系统引入的外部依赖越多,越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了,ABCD 四个系统还好好的,没啥问题,你偏加个 MQ 进来,万一 MQ 挂了咋整?MQ 一挂,整套系统崩溃,你不就完了?如何保证消息队列的高可用,可以点击这里查看。 系统复杂度提高 硬生生加个 MQ 进来,你怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性?头大头大,问题一大堆,痛苦不已。 一致性问题 A 系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是 BCD 三个系统那里,BD 两个系统写库成功了,结果 C 系统写库失败了,咋整?你这数据就不一致了。 所以消息队列实际是一种非常复杂的架构,你引入它有很多好处,但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉,做好之后,你会发现,妈呀,系统复杂度提升了一个数量级,也许是复杂了 10 倍。但是关键时刻,用,还是得用的。 综上,各种对比之后,有如下建议: 一般的业务系统要引入 MQ,最早大家都用 ActiveMQ,但是现在确实大家用的不多了,没经过大规模吞吐量场景的验证,社区也不是很活跃,所以大家还是算了吧,我个人不推荐用这个了; 后来大家开始用 RabbitMQ,但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它,对公司而言,几乎处于不可控的状态,但是确实人家是开源的,比较稳定的支持,活跃度也高; 不过现在确实越来越多的公司会去用 RocketMQ,确实很不错,毕竟是阿里出品,但社区可能有突然黄掉的风险(目前 RocketMQ 已捐给 Apache,但 GitHub 上的活跃度其实不算高)对自己公司技术实力有绝对自信的,推荐用 RocketMQ,否则回去老老实实用 RabbitMQ 吧,人家有活跃的开源社区,绝对不会黄。 所以中小型公司,技术实力较为一般,技术挑战不是特别高,用 RabbitMQ 是不错的选择;大型公司,基础架构研发实力较强,用 RocketMQ 是很好的选择。 如果是大数据领域的实时计算、日志采集等场景,用 Kafka 是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范。

剑曼红尘 2020-04-16 16:34:44 0 浏览量 回答数 0

回答

Redis里的数据不立刻更新,等redis里数据自然过期。然后去DB里取,顺带重新set redis。这种用法被称作“Cache Aside”。好处是代码比较简单,坏处是会有一段时间DB和Redis里的数据不一致。这个不一致的时间取决于redis里数据设定的有效期,比如10min。但如果Redis里数据没设置有效期,这招就不灵了。2. 更新DB时总是不直接触碰DB,而是通过代码。而代码做的显式更新DB,然后马上del掉redis里的数据。在下次取数据时,模式就恢复到了上一条说的方式。这也算是一种Cache Aside的变体。这要做的好处是,数据的一致性会比较好,一般正常情况下,数据不一致的时间会在1s以下,对于绝大部分的场景是足够了。但是有极少几率,由于更新时序,下Redis数据会和DB不一致(这个有文章解释,这里不展开)。Cache Aside,就是“Cache”在DB访问的主流程上帮个忙1和2的做法常规上被称为“Cache“。而且因为1有更新不及时的问题,2有极端情况下数据会不一致的问题,所以常规Cache代码会把1+2组合起来,要求Redis里的数据必须有过期时间,并且不能太长,这样即便是不一致也能混过去。同时如果是主动对数据进行更新,Cache的数据更新也会比较及时。并且2并不一定总是行得通。比如OLTP的服务在前面是Cache+DB的模式,而数据是由后台管理系统来更新的,总是不会触碰OLTP服务,更不会动Cache。这时将Redis看作是存储也算是一种方案。就是:3. Redis里的数据总是不过期,但是有个背景更新任务(“定时执行的代码” 或者 “被队列驱动的代码)读取db,把最新的数据塞给Redis。这种做法将Redis看作是“存储”。访问者不知道背后的实际数据源,只知道Redis是唯一可以取的数据的地方。当实际数据源更新时,背景更新任务来将数据更新到Redis。这时还是会存在Redis和实际数据源不一致的问题。如果是定时任务,最长的不一致时长就是更新任务的执行间隔;如果是用类似于队列的方式来更新,那么不一致时间取决于队列产生和消费的延迟。常用的队列(或等价物)有Redis(怎么还是Redis),Kafka,AMQ,RMQ,binglog,log文件,阿里的canal等。Cache当作“存储”来用,访问者只看得到Cache这种做法还有一种变体Write Through,写入时直接写DB,DB把数据更新Cache,而读取时读Cache。Write Through + Cache当存储以上方式无论如何都会有一段时间Redis和DB会不一致。实践上,这个不一致时间短则几十ms,长可以到几十分钟。这种程度的一致性对于很多业务场景都已经足够了。很多时候,用户无法区分自己读取的是Redis还是DB,只能读取到其中的一个。这时数据看起来直觉上是没问题的就可以接受了。只要不出现,用户先看见了数据是A,然后看到数据是B,之后一刷新,又看到A的尴尬场景就行了。(这也可以部份解释为啥用经常使用共享式的Cache而不是本地Cache方案)。但对于有些业务,比如协作文档编辑,电商秒杀的扣库存,银行转账等,以上的做法就不够用了。解决办法也有两大类。第一种是不要用Redis,只用DB。或者更直接点说是“只要一个单点的数据源”。这样肯定就没有一致性问题,代价就是CAP中因为CP被满足,因此A被牺牲掉。这就是为啥银行一系统升级就要停服务的原因。当然实际上也有CAP兼顾,但是C要的强一点,A就得弱一点,但不至于完全牺牲掉的做法。这里不展开。另外一种保证一致性的做法就是用某种分布式协议一致性来做,大致可以归结到SAGA或者TCC - 这两种需要业务代码的大量配合。通过业务代码来补偿一致性。2PC, 3PC - 现实当中有XA协议。比如Ehcache是支持XA协议的。但是性能表现不佳,运维也麻烦,我比较少见到实际这么干的。基于Paxos或者Raft的分布式锁,然后对Redis和DB进行双写,但是除非客户端和服务器么次都去访问分布式锁,也会有一点点不一致的问题。这实际上相当于将多个地方的一致性控制交给了分布式锁的集中维护。这些做法实施复杂度和运维复杂度太高,以至于对于像Redis + DB这种场景基本上没人这么干。本质上大家用Redis一般也就是想做个Cache而已。这些方案通常被用到比如多数据中心数据一致性维护的系统中。综上,除了单点DB存储之外的方案,其一致性面临的窘境是要么,接受“最终一致”,但到底多久之后一致,不一致时表现怎么样,有很多种做法。分布式一致性有各种各样的模型,比如线性一致性、顺序一致性等。他们都是在“不一致”和“强一致”之间提供某种折衷。这些折衷大量应用于我们常见的诸多业务之中、如社交、IM、电商不触及钱的地方等要么,要求必须强一致。那么在分布式条件下就要牺牲A。比如访问一个Cache,Cache知道自己的数据不是最新的,就要和DB去Sync,Sync的过程中DB的数据还不能改。期间访问者要不收到一个错误“数据不同步,不能访问”,要不就卡在那里等着同步完成。个人以为,这还不如干脆就不要Cache,在维护强一致的同时,用其他方式来优化访问性能。最最后提醒下,本文有很多不严谨的地方,包括对Cache的形式总结其实只有典型的几种,实际可能的要多得多;再比如对一致性的介绍也非常粗浅,原因是为了让初学者有一点点概念,能看得进去(就这样,已经很长了,评论区里也有人表示接受不了)。对于分布式和其一致性的完整知识的学习需要耗费大量的精力,Good Luck & Best Wishes。 来源:云原生后端社区

保持可爱mmm 2020-04-22 10:23:06 0 浏览量 回答数 0

问题

如何设计才可以让系统从未分库分表动态切换到分库分表上?【Java问答】42期

剑曼红尘 2020-06-22 11:05:45 34 浏览量 回答数 1

问题

ES 生产集群的部署架构是什么?每个索引的数据量大概有多少?【Java问答学堂】29期

剑曼红尘 2020-05-29 20:07:04 0 浏览量 回答数 0

问题

安全组详解,新手必看教程

我的中国 2019-12-01 21:51:56 92179 浏览量 回答数 37

回答

面试官心理分析 这个问题是肯定要问的,说白了,就是看你有没有实际干过 es,因为啥?其实 es 性能并没有你想象中那么好的。很多时候数据量大了,特别是有几亿条数据的时候,可能你会懵逼的发现,跑个搜索怎么一下 5~10s,坑爹了。第一次搜索的时候,是 5~10s,后面反而就快了,可能就几百毫秒。 你就很懵,每个用户第一次访问都会比较慢,比较卡么?所以你要是没玩儿过 es,或者就是自己玩玩儿 demo,被问到这个问题容易懵逼,显示出你对 es 确实玩儿的不怎么样? 面试题剖析 说实话,es 性能优化是没有什么银弹的,啥意思呢?就是不要期待着随手调一个参数,就可以万能的应对所有的性能慢的场景。也许有的场景是你换个参数,或者调整一下语法,就可以搞定,但是绝对不是所有场景都可以这样。 性能优化的杀手锏——filesystem cache 你往 es 里写的数据,实际上都写到磁盘文件里去了,查询的时候,操作系统会将磁盘文件里的数据自动缓存到 filesystem cache 里面去。 es 的搜索引擎严重依赖于底层的 filesystem cache,你如果给 filesystem cache 更多的内存,尽量让内存可以容纳所有的 idx segment file 索引数据文件,那么你搜索的时候就基本都是走内存的,性能会非常高。 性能差距究竟可以有多大?我们之前很多的测试和压测,如果走磁盘一般肯定上秒,搜索性能绝对是秒级别的,1秒、5秒、10秒。但如果是走 filesystem cache,是走纯内存的,那么一般来说性能比走磁盘要高一个数量级,基本上就是毫秒级的,从几毫秒到几百毫秒不等。 这里有个真实的案例。某个公司 es 节点有 3 台机器,每台机器看起来内存很多,64G,总内存就是 64 * 3 = 192G。每台机器给 es jvm heap 是 32G,那么剩下来留给 filesystem cache 的就是每台机器才 32G,总共集群里给 filesystem cache 的就是 32 * 3 = 96G 内存。而此时,整个磁盘上索引数据文件,在 3 台机器上一共占用了 1T 的磁盘容量,es 数据量是 1T,那么每台机器的数据量是 300G。这样性能好吗? filesystem cache 的内存才 100G,十分之一的数据可以放内存,其他的都在磁盘,然后你执行搜索操作,大部分操作都是走磁盘,性能肯定差。 归根结底,你要让 es 性能要好,最佳的情况下,就是你的机器的内存,至少可以容纳你的总数据量的一半。 根据我们自己的生产环境实践经验,最佳的情况下,是仅仅在 es 中就存少量的数据,就是你要用来搜索的那些索引,如果内存留给 filesystem cache 的是 100G,那么你就将索引数据控制在 100G 以内,这样的话,你的数据几乎全部走内存来搜索,性能非常之高,一般可以在 1 秒以内。 比如说你现在有一行数据。id,name,age .... 30 个字段。但是你现在搜索,只需要根据 id,name,age 三个字段来搜索。如果你傻乎乎往 es 里写入一行数据所有的字段,就会导致说 90% 的数据是不用来搜索的,结果硬是占据了 es 机器上的 filesystem cache 的空间,单条数据的数据量越大,就会导致 filesystem cahce 能缓存的数据就越少。其实,仅仅写入 es 中要用来检索的少数几个字段就可以了,比如说就写入 es id,name,age 三个字段,然后你可以把其他的字段数据存在 mysql/hbase 里,我们一般是建议用 es + hbase 这么一个架构。 hbase 的特点是适用于海量数据的在线存储,就是对 hbase 可以写入海量数据,但是不要做复杂的搜索,做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了。从 es 中根据 name 和 age 去搜索,拿到的结果可能就 20 个 doc id,然后根据 doc id 到 hbase 里去查询每个 doc id 对应的完整的数据,给查出来,再返回给前端。 写入 es 的数据最好小于等于,或者是略微大于 es 的 filesystem cache 的内存容量。然后你从 es 检索可能就花费 20ms,然后再根据 es 返回的 id 去 hbase 里查询,查 20 条数据,可能也就耗费个 30ms,可能你原来那么玩儿,1T 数据都放 es,会每次查询都是 5~10s,现在可能性能就会很高,每次查询就是 50ms。 数据预热 假如说,哪怕是你就按照上述的方案去做了,es 集群中每个机器写入的数据量还是超过了 filesystem cache 一倍,比如说你写入一台机器 60G 数据,结果 filesystem cache 就 30G,还是有 30G 数据留在了磁盘上。 其实可以做数据预热。 举个例子,拿微博来说,你可以把一些大V,平时看的人很多的数据,你自己提前后台搞个系统,每隔一会儿,自己的后台系统去搜索一下热数据,刷到 filesystem cache 里去,后面用户实际上来看这个热数据的时候,他们就是直接从内存里搜索了,很快。 或者是电商,你可以将平时查看最多的一些商品,比如说 iphone 8,热数据提前后台搞个程序,每隔 1 分钟自己主动访问一次,刷到 filesystem cache 里去。 对于那些你觉得比较热的、经常会有人访问的数据,最好做一个专门的缓存预热子系统,就是对热数据每隔一段时间,就提前访问一下,让数据进入 filesystem cache 里面去。这样下次别人访问的时候,性能一定会好很多。 冷热分离 es 可以做类似于 mysql 的水平拆分,就是说将大量的访问很少、频率很低的数据,单独写一个索引,然后将访问很频繁的热数据单独写一个索引。最好是将冷数据写入一个索引中,然后热数据写入另外一个索引中,这样可以确保热数据在被预热之后,尽量都让他们留在 filesystem os cache 里,别让冷数据给冲刷掉。 你看,假设你有 6 台机器,2 个索引,一个放冷数据,一个放热数据,每个索引 3 个 shard。3 台机器放热数据 index,另外 3 台机器放冷数据 index。然后这样的话,你大量的时间是在访问热数据 index,热数据可能就占总数据量的 10%,此时数据量很少,几乎全都保留在 filesystem cache 里面了,就可以确保热数据的访问性能是很高的。但是对于冷数据而言,是在别的 index 里的,跟热数据 index 不在相同的机器上,大家互相之间都没什么联系了。如果有人访问冷数据,可能大量数据是在磁盘上的,此时性能差点,就 10% 的人去访问冷数据,90% 的人在访问热数据,也无所谓了。 document 模型设计 对于 MySQL,我们经常有一些复杂的关联查询。在 es 里该怎么玩儿,es 里面的复杂的关联查询尽量别用,一旦用了性能一般都不太好。 最好是先在 Java 系统里就完成关联,将关联好的数据直接写入 es 中。搜索的时候,就不需要利用 es 的搜索语法来完成 join 之类的关联搜索了。 document 模型设计是非常重要的,很多操作,不要在搜索的时候才想去执行各种复杂的乱七八糟的操作。es 能支持的操作就那么多,不要考虑用 es 做一些它不好操作的事情。如果真的有那种操作,尽量在 document 模型设计的时候,写入的时候就完成。另外对于一些太复杂的操作,比如 join/nested/parent-child 搜索都要尽量避免,性能都很差的。 分页性能优化 es 的分页是较坑的,为啥呢?举个例子吧,假如你每页是 10 条数据,你现在要查询第 100 页,实际上是会把每个 shard 上存储的前 1000 条数据都查到一个协调节点上,如果你有个 5 个 shard,那么就有 5000 条数据,接着协调节点对这 5000 条数据进行一些合并、处理,再获取到最终第 100 页的 10 条数据。 分布式的,你要查第 100 页的 10 条数据,不可能说从 5 个 shard,每个 shard 就查 2 条数据,最后到协调节点合并成 10 条数据吧?你必须得从每个 shard 都查 1000 条数据过来,然后根据你的需求进行排序、筛选等等操作,最后再次分页,拿到里面第 100 页的数据。你翻页的时候,翻的越深,每个 shard 返回的数据就越多,而且协调节点处理的时间越长,非常坑爹。所以用 es 做分页的时候,你会发现越翻到后面,就越是慢。 我们之前也是遇到过这个问题,用 es 作分页,前几页就几十毫秒,翻到 10 页或者几十页的时候,基本上就要 5~10 秒才能查出来一页数据了。 有什么解决方案吗? 不允许深度分页(默认深度分页性能很差) 跟产品经理说,你系统不允许翻那么深的页,默认翻的越深,性能就越差。 类似于 app 里的推荐商品不断下拉出来一页一页的 类似于微博中,下拉刷微博,刷出来一页一页的,你可以用 scroll api,关于如何使用,自行上网搜索。 scroll 会一次性给你生成所有数据的一个快照,然后每次滑动向后翻页就是通过游标 scroll_id 移动,获取下一页下一页这样子,性能会比上面说的那种分页性能要高很多很多,基本上都是毫秒级的。 但是,唯一的一点就是,这个适合于那种类似微博下拉翻页的,不能随意跳到任何一页的场景。也就是说,你不能先进入第 10 页,然后去第 120 页,然后又回到第 58 页,不能随意乱跳页。所以现在很多产品,都是不允许你随意翻页的,app,也有一些网站,做的就是你只能往下拉,一页一页的翻。 初始化时必须指定 scroll 参数,告诉 es 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时,否则可能因为超时而失败。 除了用 scroll api,你也可以用 search_after 来做,search_after 的思想是使用前一页的结果来帮助检索下一页的数据,显然,这种方式也不允许你随意翻页,你只能一页页往后翻。初始化时,需要使用一个唯一值的字段作为 sort 字段。 往期回顾: 【Java问答学堂】1期 为什么使用消息队列?消息队列有什么优点和缺点?Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景? 【Java问答学堂】2期 如何保证消息队列的高可用? 【Java问答学堂】3期 如何保证消息不被重复消费?或者说,如何保证消息消费的幂等性? 【Java问答学堂】4期 如何保证消息的可靠性传输?(如何处理消息丢失的问题?) 【Java问答学堂】5期 如何保证消息的顺序性? 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题? 【Java问答学堂】7期 如果让你写一个消息队列,该如何进行架构设计? 【Java问答学堂】8期 es 的分布式架构原理能说一下么(es 是如何实现分布式的啊)? 【Java问答学堂】9期 es 写入数据的工作原理是什么啊?es 查询数据的工作原理是什么啊?

剑曼红尘 2020-04-28 14:17:05 0 浏览量 回答数 0

问题

【Java问答学堂】10期 es 在数据量很大的情况下(数十亿级别)如何提高查询效率啊?

剑曼红尘 2020-04-28 14:16:56 0 浏览量 回答数 1

回答

不设置这两个Timeout也是可以的,因为程序会根据你的操作系统不同使用系统默认的timeout制。就像@蛮大人123说的那样,这两个参数要根据你的网络环境、业务逻辑、以及程序运行状况做适当调整。比如connection timeout这个参数。当你的程序通过百兆局域网去远程连接某台服务器上的某个服务端口时,你的网络环境、客户端性能都很好,如果对方服务端口没开,或是不能及时响应你的连接请求,你就没有必要让你的程序(也就是客户端)傻傻的在哪儿等待,而是立刻返回一个消息给用户,告诉用户服务器端无响应。但是,如果你的网络环境很差,比如用28.8kbps的modem做的网络连接,或是你要连接的服务端口非常繁忙,可能你的连接请求被扔到连接队列里在等待,那么你就应该适当放宽connection timeout,以便程序可以正常连接到服务器。像connection这种操作,在程序的一个线程中往往都是同步业务,你不可能跳过connection去直接登录到服务器,所以适当调整timeout既不会让你的客户白白浪费去等待,又可以提高用户体验,就像@蛮大人123说的那样。同理,ReadTimeout是对数据传输时进行的超时控制。用户从服务器下载一个2G的文件,但是由于用户的网络状况不好,时断时续,你总不能让服务器一直给你开一个连接窗口吧,那样服务器啥也别干了,光伺候这一个用户了,尤其是当所访问的资源有资源锁的issue的时候,更不可能把一个重要的资源一直hang在那里,哪怕是管理想操作都不能操作了。

rickqin 2019-12-02 02:07:53 0 浏览量 回答数 0

问题

ES 在数据量很大的情况下(数十亿级别)如何提高查询效率啊?【Java问答学堂】28期

剑曼红尘 2020-05-28 09:45:28 15 浏览量 回答数 1

问题

[精品问答]Java一百问第一期

问问小秘 2019-12-01 21:51:20 791 浏览量 回答数 1

问题

如何自己设计一个类似 Dubbo 的 RPC 框架?【Java问答学堂】54期

剑曼红尘 2020-07-09 10:30:28 30 浏览量 回答数 1

回答

三个字,不可能######回复 @DanceCoder : 没有这种数据库管理员,如果是系统里的管理员,倒是可以通过系统代码,实现管理员只能管理不能查看的逻辑。数据库本身的管理员不行,除非让数据库管理员都进不了数据库,那还管理啥。######回复 @乌龟壳 : 面试官说可以执行增删改查,就是直接在控制台执行SQL语句的那种。######回复 @HankeBoom : 如果有背景就可能不一样,比如说的其实是所谓的数据库管理员之类的,就看看服务器状态那些,数据库都没权限进去######哈哈哈,面试官好坏。。。。。######你确认他不是在出脑筋急转弯? ######不知道,根据我仅有的面试经验,一般都是先问一些基础的问题。我也不知道他为什么问这么摸不着头脑的问题。难道是在考察我的解决问题能力?###### 数据库管理员没有权限看数据库,感觉就像厨师不能进厨房一样。######面试官的意思是不要在管理员权限方面限制不同权限级别的管理员###### 在java程序是对用户名和密码进行了加密后存入数据库的,登录的时候时候再提取数据库的数据进行相反的解密过程,如果一致,才通过 根据你的描述,管理员A又可以管理服务器后台,又可以管理数据库,那只能说明管理员只能为一个(多了就权责不分了),当然最好的是 不要给A日志信息查看权限,要不然就他就可以做到天衣无缝。 以上是个人对数据安全性的理解 下面废话:1:不考虑数据库权限、不考虑加密、不考虑数据库类型,说明数据库安全性有问题。2:面试官的回答“登录修改用户密码和然后就可以登录了。” ,有点sb思维,我都看得到密码了,还用修改后台的密码,还要脱裤子放屁(多此一举) ######哈哈哈,面试官确实好坏###### 这种东西只有在登录的时候处理吧. 数据库都是持久性的东西, 不管如何加密. 只要修改成一个我知道的明文加密的数据不就行了? 所以,还是在登录的后台做处理. 比如加密的是根据用户输入的密码加上用户名之类的处理过的密码. 那么数据库管理员不知道后台的处理逻辑, 修改了数据库也无用. ######长知识了,谢谢######66666###### 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 ######就是性能堪忧######这个有点厉害啊###### 引用来自“cys1357”的评论 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 可是都说了不允许加密了,实在想不出不加密怎么办了######你需要了解MySQL的“视图”是干嘛的。。。。。。。######视图不是也可以执行改数据操作吗###### 引用来自“cys1357”的评论 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 引用来自“钛元素”的评论可是都说了不允许加密了,实在想不出不加密怎么办了 上面的加密只是为了去掉多个片段记录中用户名的相关性,让管理员无法通过搜索找出所有和这个用户名相关的记录项,不需要解密,只是一种变换算法。

kun坤 2020-06-08 10:04:20 0 浏览量 回答数 0

问题

【Java问答学堂】9期 es 写入数据的工作原理是什么啊?es 查询数据的工作原理是什么啊?

剑曼红尘 2020-04-27 14:35:38 0 浏览量 回答数 1

回答

SciHub Desktop这个软件的最初两个版本是用 Python + TK 写的 GUI 程序,主要是为了方便广大研究生突破权限下载英文文献。内含多个文献下载数据源,只要输入文献的 DOI 号,回车就可以自动下载文献全文,非常方便,目前仅网盘的下载量就超过了 30 万人次。Tsing:SciHub Desktop 桌面版软件官方发布页面​ zhuanlan.zhihu.com2. HistCite Pro这个软件是基于 HistCite 内核开发的免安装易用版本,使用 Python 对从 Web of Science 数据库中导出的数据文件进行预处理,然后进行文献引文分析,快速分析出某个研究领域最具有价值的文献和作者,目前也得到了数万用户的使用。Tsing:文献引文分析利器 HistCite 详细使用教程暨 HistCite Pro 首发页面​ zhuanlan.zhihu.com3. 上学吧答案神器这款软件是最近才写的,主要实现的是无限制获取上学吧网站上的题目答案(绕过 IP 限制),并实现了自动识别验证码,只用输入某个题目的网址,即可一键获取答案,速度非常快。Tsing:自动识别验证码无限次获取上学吧的题目答案​ zhuanlan.zhihu.com 4. 破解观看中科大网络课堂 由于 本科四年都在科大,所以那时候也写了好多关于科大的脚本(正是因为太喜欢科大了才会去折腾这些哈),虽然目前有些已经失效了,但是还是值得放出来纪念一下的。 中国科学技术大学网络课堂汇集了很多知名教授的授课视频,以及最新的大牛讲座视频,内容相当丰富,但是这些视频只面向校内 IP 开放。后来不小心找到了网站上的一个漏洞,用 Python 写了不到 10 行代码就可以获取真实视频地址,这样就可以在校外看视频了。(这个漏洞目前已经被修复了,大家就不要找我要代码了哈~) 另外还简单写了一个 GUI 界面,打包成 exe 单软件给室友用,都说挺好用的哈。 5. 抓取研究生系统内全部学生姓名学号及选课信息登录中国科学技术大学的研究生综合系统,可以看到每一门课选课的学生姓名和学号,当时就想到做一个这样的系统,输入任何姓名或学号就可以看到他所有的选课信息。 点击每门课的已选人数链接,可以看到所有的选课学生姓名和学号: 下面利用 requests 的模拟登录功能,先获取全部课程的链接,然后逐个抓取所有课程的选课信息。(为了保护学生信息,对程序的关键部分进行了模糊处理。) 这样就获取了一个巨大的 json 文件,里面全都是学生的姓名、学号以及选课信息: 有了这个 json 文件,我们可以写入数据库,也可以直接利用 json 文件来查询: 为了方便其他人使用,基于上面的数据我开发了一个在线查询网站(目前已下线): 输入姓名或者学号都可以直接查询别人的选课信息: 6. 扫描研究生系统上的弱密码用户基于上面获得的研究生学号,很容易利用 Python 批量尝试登录研究生系统,密码就用 123456 这样的弱密码,然后可以获得身份证号码等重要信息。 这样就得到了使用 123456 作为密码的用户信息,所以在此提醒大家一定不要使用弱密码,希望下面的同学早日修改密码。 7. 模拟登录图书馆系统并自动续借以前收到借阅图书到期通知短信,就会运行一下这个程序,然后就自动续借了,这样就可以再看一个月了。不过后来科大图书馆系统升级了,因此这个方法也就失效了。 运行就是这样的,自动续借成功,看到的链接就是每本书的续借链接。 8. 云短信网站上的验证码短信来源分析这个网站提供了很多免费的临时手机号,用这些公用的手机号你可以注册一些好玩的(或者你懂的)网站和APP,而不用担心个人信息的泄露。于是我用 Python 写了一个爬虫脚本,自动翻页抓取了部分短信内容,然后解析出其中的信息来源并分析一下频次,就发现好几个看名字就挺有意思的 APP 压根没有听过呀,看来是时候用短信验证码的方式登录看看去啦~Tsing:Python爬虫:大家用公共的手机号干了啥?​ zhuanlan.zhihu.com 9. 给钓鱼网站批量提交垃圾信息经常会收到含有钓鱼网站链接的短信的,一般都是盗取 QQ 密码的偏多,其实可以使用 Python 来批量给对方的服务器提交垃圾数据(需要先抓包),这样骗子看到信息之后就不知道哪些是真的哪些是假的了,说不定可以解救一部分填了密码的同学。Tsing:偶遇一个钓鱼网站,于是就简单玩了一下...​ zhuanlan.zhihu.com10. 网易云音乐批量下载可以批量下载网易云音乐热歌榜的歌曲,可以自己设定数量,速度非常快。 # 网易云音乐批量下载 # Tsing 2019.03.28 # 首先,找到你要下载的歌曲,用网页版打开,复制链接中的歌曲ID,如:http://music.163.com/#/song?id=476592630 这个链接ID就是 476592630 # 然后将ID替换到链接 http://music.163.com/song/media/outer/url?id=ID.mp3 中的ID位置即可获得歌曲的外链:http://music.163.com/song/media/outer/url?id=476592630.mp3 import requests # 用于获取网页内容的模块 from bs4 import BeautifulSoup # 用于解析网页源代码的模块 header={ # 伪造浏览器头部,不然获取不到网易云音乐的页面源代码。 'User-Agent':'Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36', 'Referer':'http://93.174.95.27', } link = "http://music.163.com/discover/toplist?id=3778678" # 这是网易云音乐热歌榜的链接(其实是嵌套在网页里面含有歌曲数据的页面框架的真实链接) r = requests.get(link, headers=header) # 通过 requests 模块的 get 方法获取网页数据 html = r.content # 获取网页内容 soup = BeautifulSoup(html, "html.parser") # 通过 BeautifulSoup 模块解析网页,具体请参考官方文档。 songs = soup.find("ul", class_="f-hide").select("a", limit=10) # 通过分析网页源代码发现排行榜中的歌曲信息全部放在类名称为 f-hide 的 ul 中,于是根据特殊的类名称查找相应 ul,然后找到里面的全部 a 标签,限制数量为10,即排行榜的前 10 首歌。

游客bnlxddh3fwntw 2020-04-25 14:35:08 0 浏览量 回答数 0

回答

前言 这期我想写很久了,但是因为时间的原因一直拖到了现在,我以为一两天就写完了,结果从构思到整理资料,再到写出来用了差不多一周的时间吧。 你们也知道丙丙一直都是创作鬼才来的,所以我肯定不会一本正经的写,我想了好几个切入点,最后决定用一个完整的电商系统作为切入点,带着大家看看,我们需要学些啥,我甚至还收集配套视频和资料,暖男石锤啊,这期是呕心沥血之作,不要白嫖了。 正文 在写这个文章之前,我花了点时间,自己臆想了一个电商系统,基本上算是麻雀虽小五脏俱全,我今天就用它开刀,一步步剖析,我会讲一下我们可能会接触的技术栈可能不全,但是够用,最后给个学习路线。 Tip:请多欣赏一会,每个点看一下,看看什么地方是你接触过的,什么技术栈是你不太熟悉的,我觉得还算是比较全的,有什么建议也可以留言给我。 不知道大家都看了一下没,现在我们就要庖丁解牛了,我从上到下依次分析。 前端 你可能会会好奇,你不是讲后端学习路线嘛,为啥还有前端的部分,我只能告诉你,傻瓜,肤浅。 我们可不能闭门造车,谁告诉你后端就不学点前端了? 前端现在很多也了解后端的技术栈的,你想我们去一个网站,最先接触的,最先看到的是啥? 没错就是前端,在大学你要是找不到专门的前端同学,去做系统肯定也要自己顶一下前端的,那我觉得最基本的技术栈得熟悉和了解吧,丙丙现在也是偶尔会开发一下我们的管理系统主要是VUE和React。 在这里我列举了我目前觉得比较简单和我们后端可以了解的技术栈,都是比较基础的。 作为一名后端了解部分前端知识还是很有必要的,在以后开发的时候,公司有前端那能帮助你前后端联调更顺畅,如果没前端你自己也能顶一下简单的页面。 HTML、CSS、JS、Ajax我觉得是必须掌握的点,看着简单其实深究或者去操作的话还是有很多东西的,其他作为扩展有兴趣可以了解,反正入门简单,只是精通很难很难。 在这一层不光有这些还有Http协议和Servlet,request、response、cookie、session这些也会伴随你整个技术生涯,理解他们对后面的你肯定有不少好处。 Tip:我这里最后删除了JSP相关的技术,我个人觉得没必要学了,很多公司除了老项目之外,新项目都不会使用那些技术了。 前端在我看来比后端难,技术迭代比较快,知识好像也没特定的体系,所以面试大厂的前端很多朋友都说难,不是技术多难,而是知识多且复杂,找不到一个完整的体系,相比之下后端明朗很多,我后面就开始讲后端了。 网关层: 互联网发展到现在,涌现了很多互联网公司,技术更新迭代了很多个版本,从早期的单机时代,到现在超大规模的互联网时代,几亿人参与的春运,几千亿成交规模的双十一,无数互联网前辈的造就了现在互联网的辉煌。 微服务,分布式,负载均衡等我们经常提到的这些名词都是这些技术在场景背后支撑。 单机顶不住,我们就多找点服务器,但是怎么将流量均匀的打到这些服务器上呢? 负载均衡,LVS 我们机器都是IP访问的,那怎么通过我们申请的域名去请求到服务器呢? DNS 大家刷的抖音,B站,快手等等视频服务商,是怎么保证同时为全国的用户提供快速的体验? CDN 我们这么多系统和服务,还有这么多中间件的调度怎么去管理调度等等? zk 这么多的服务器,怎么对外统一访问呢,就可能需要知道反向代理的服务器。 Nginx 这一层做了反向负载、服务路由、服务治理、流量管理、安全隔离、服务容错等等都做了,大家公司的内外网隔离也是这一层做的。 我之前还接触过一些比较有意思的项目,所有对外的接口都是加密的,几十个服务会经过网关解密,找到真的路由再去请求。 这一层的知识点其实也不少,你往后面学会发现分布式事务,分布式锁,还有很多中间件都离不开zk这一层,我们继续往下看。 服务层: 这一层有点东西了,算是整个框架的核心,如果你跟我帅丙一样以后都是从事后端开发的话,我们基本上整个技术生涯,大部分时间都在跟这一层的技术栈打交道了,各种琳琅满目的中间件,计算机基础知识,Linux操作,算法数据结构,架构框架,研发工具等等。 我想在看这个文章的各位,计算机基础肯定都是学过的吧,如果大学的时候没好好学,我觉得还是有必要再看看的。 为什么我们网页能保证安全可靠的传输,你可能会了解到HTTP,TCP协议,什么三次握手,四次挥手。 还有进程、线程、协程,什么内存屏障,指令乱序,分支预测,CPU亲和性等等,在之后的编程生涯,如果你能掌握这些东西,会让你在遇到很多问题的时候瞬间get到点,而不是像个无头苍蝇一样乱撞(然而丙丙还做得不够)。 了解这些计算机知识后,你就需要接触编程语言了,大学的C语言基础会让你学什么语言入门都会快点,我选择了面向对象的JAVA,但是也不知道为啥现在还没对象。 JAVA的基础也一样重要,面向对象(包括类、对象、方法、继承、封装、抽象、 多态、消息解析等),常见API,数据结构,集合框架,设计模式(包括创建型、结构型、行为型),多线程和并发,I/O流,Stream,网络编程你都需要了解。 代码会写了,你就要开始学习一些能帮助你把系统变得更加规范的框架,SSM可以会让你的开发更加便捷,结构层次更加分明。 写代码的时候你会发现你大学用的Eclipse在公司看不到了,你跟大家一样去用了IDEA,第一天这是什么玩意,一周后,真香,但是这玩意收费有点贵,那免费的VSCode真的就是不错的选择了。 代码写的时候你会接触代码的仓库管理工具maven、Gradle,提交代码的时候会去写项目版本管理工具Git。 代码提交之后,发布之后你会发现很多东西需要自己去服务器亲自排查,那Linux的知识点就可以在里面灵活运用了,查看进程,查看文件,各种Vim操作等等。 系统的优化很多地方没优化的空间了,你可能会尝试从算法,或者优化数据结构去优化,你看到了HashMap的源码,想去了解红黑树,然后在算法网上看到了二叉树搜索树和各种常见的算法问题,刷多了,你也能总结出精华所在,什么贪心,分治,动态规划等。 这么多个服务,你发现HTTP请求已经开始有点不满足你的需求了,你想开发更便捷,像访问本地服务一样访问远程服务,所以我们去了解了Dubbo,Spring cloud。 了解Dubbo的过程中,你发现了RPC的精华所在,所以你去接触到了高性能的NIO框架,Netty。 代码写好了,服务也能通信了,但是你发现你的代码链路好长,都耦合在一起了,所以你接触了消息队列,这种异步的处理方式,真香。 他还可以帮你在突发流量的时候用队列做缓冲,但是你发现分布式的情况,事务就不好管理了,你就了解到了分布式事务,什么两段式,三段式,TCC,XA,阿里云的全局事务服务GTS等等。 分布式事务的时候你会想去了解RocketMQ,因为他自带了分布式事务的解决方案,大数据的场景你又看到了Kafka。 我上面提到过zk,像Dubbo、Kafka等中间件都是用它做注册中心的,所以很多技术栈最后都组成了一个知识体系,你先了解了体系中的每一员,你才能把它们联系起来。 服务的交互都从进程内通信变成了远程通信,所以性能必然会受到一些影响。 此外由于很多不确定性的因素,例如网络拥塞、Server 端服务器宕机、挖掘机铲断机房光纤等等,需要许多额外的功能和措施才能保证微服务流畅稳定的工作。 **Spring Cloud **中就有 Hystrix 熔断器、Ribbon客户端负载均衡器、Eureka注册中心等等都是用来解决这些问题的微服务组件。 你感觉学习得差不多了,你发现各大论坛博客出现了一些前沿技术,比如容器化,你可能就会去了解容器化的知识,像**Docker,Kubernetes(K8s)**等。 微服务之所以能够快速发展,很重要的一个原因就是:容器化技术的发展和容器管理系统的成熟。 这一层的东西呢其实远远不止这些的,我不过多赘述,写多了像个劝退师一样,但是大家也不用慌,大部分的技术都是慢慢接触了,工作中慢慢去了解,去深入的。 好啦我们继续沿着图往下看,那再往下是啥呢? 数据层: 数据库可能是整个系统中最值钱的部分了,在我码文字的前一天,刚好发生了微盟程序员删库跑路的操作,删库跑路其实是我们在网上最常用的笑话,没想到还是照进了现实。 这里也提一点点吧,36小时的故障,其实在互联网公司应该是个笑话了吧,权限控制没做好类似rm -rf 、fdisk、drop等等这样的高危命令是可以实时拦截掉的,备份,全量备份,增量备份,延迟备份,异地容灾全部都考虑一下应该也不至于这样,一家上市公司还是有点点不应该。 数据库基本的事务隔离级别,索引,SQL,主被同步,读写分离等都可能是你学的时候要了解到的。 上面我们提到了安全,不要把鸡蛋放一个篮子的道理大家应该都知道,那分库的意义就很明显了,然后你会发现时间久了表的数据大了,就会想到去接触分表,什么TDDL、Sharding-JDBC、DRDS这些插件都会接触到。 你发现流量大的时候,或者热点数据打到数据库还是有点顶不住,压力太大了,那非关系型数据库就进场了,Redis当然是首选,但是MongoDB、memcache也有各自的应用场景。 Redis使用后,真香,真快,但是你会开始担心最开始提到的安全问题,这玩意快是因为在内存中操作,那断点了数据丢了怎么办?你就开始阅读官方文档,了解RDB,AOF这些持久化机制,线上用的时候还会遇到缓存雪崩击穿、穿透等等问题。 单机不满足你就用了,他的集群模式,用了集群可能也担心集群的健康状态,所以就得去了解哨兵,他的主从同步,时间久了Key多了,就得了解内存淘汰机制…… 他的大容量存储有问题,你可能需要去了解Pika…. 其实远远没完,每个的点我都点到为止,但是其实要深究每个点都要学很久,我们接着往下看。 实时/离线/大数据 等你把几种关系型非关系型数据库的知识点,整理清楚后,你会发现数据还是大啊,而且数据的场景越来越多多样化了,那大数据的各种中间件你就得了解了。 你会发现很多场景,不需要实时的数据,比如你查你的支付宝去年的,上个月的账单,这些都是不会变化的数据,没必要实时,那你可能会接触像ODPS这样的中间件去做数据的离线分析。 然后你可能会接触Hadoop系列相关的东西,比如于Hadoop(HDFS)的一个数据仓库工具Hive,是建立在 Hadoop 文件系统之上的分布式面向列的数据库HBase 。 写多的场景,适合做一些简单查询,用他们又有点大材小用,那Cassandra就再合适不过了。 离线的数据分析没办法满足一些实时的常见,类似风控,那Flink你也得略知一二,他的窗口思想还是很有意思。 数据接触完了,计算引擎Spark你是不是也不能放过…… 搜索引擎: 传统关系型数据库和NoSQL非关系型数据都没办法解决一些问题,比如我们在百度,淘宝搜索东西的时候,往往都是几个关键字在一起一起搜索东西的,在数据库除非把几次的结果做交集,不然很难去实现。 那全文检索引擎就诞生了,解决了搜索的问题,你得思考怎么把数据库的东西实时同步到ES中去,那你可能会思考到logstash去定时跑脚本同步,又或者去接触伪装成一台MySQL从服务的Canal,他会去订阅MySQL主服务的binlog,然后自己解析了去操作Es中的数据。 这些都搞定了,那可视化的后台查询又怎么解决呢?Kibana,他他是一个可视化的平台,甚至对Es集群的健康管理都做了可视化,很多公司的日志查询系统都是用它做的。 学习路线 看了这么久你是不是发现,帅丙只是一直在介绍每个层级的技术栈,并没说到具体的一个路线,那是因为我想让大家先有个认知或者说是扫盲吧,我一样用脑图的方式汇总一下吧,如果图片被平台二压了。 资料/学习网站 Tip:本来这一栏有很多我准备的资料的,但是都是外链,或者不合适的分享方式,博客的运营小姐姐提醒了我,所以大家去公众号回复【路线】好了。 絮叨 如果你想去一家不错的公司,但是目前的硬实力又不到,我觉得还是有必要去努力一下的,技术能力的高低能决定你走多远,平台的高低,能决定你的高度。 如果你通过努力成功进入到了心仪的公司,一定不要懈怠放松,职场成长和新技术学习一样,不进则退。 丙丙发现在工作中发现我身边的人真的就是实力越强的越努力,最高级的自律,享受孤独(周末的歪哥)。 总结 我提到的技术栈你想全部了解,我觉得初步了解可能几个月就够了,这里的了解仅限于你知道它,知道他是干嘛的,知道怎么去使用它,并不是说深入了解他的底层原理,了解他的常见问题,熟悉问题的解决方案等等。 你想做到后者,基本上只能靠时间上的日积月累,或者不断的去尝试积累经验,也没什么速成的东西,欲速则不达大家也是知道的。 技术这条路,说实话很枯燥,很辛苦,但是待遇也会高于其他一些基础岗位。 所实话我大学学这个就是为了兴趣,我从小对电子,对计算机都比较热爱,但是现在打磨得,现在就是为了钱吧,是不是很现实?若家境殷实,谁愿颠沛流离。 但是至少丙丙因为做软件,改变了家庭的窘境,自己日子也向小康一步步迈过去。 说做程序员改变了我和我家人的一生可能夸张了,但是我总有一种下班辈子会因为我选择走这条路而改变的错觉。 我是敖丙,一个在互联网苟且偷生的工具人。 创作不易,本期硬核,不想被白嫖,各位的「三连」就是丙丙创作的最大动力,我们下次见! 本文 GitHub https://github.com/JavaFamily 已经收录,有大厂面试完整考点,欢迎Star。 该回答来自:敖丙

剑曼红尘 2020-03-06 11:35:37 0 浏览量 回答数 0

回答

面试官心理分析 其实这是很常见的一个问题,这俩问题基本可以连起来问。既然是消费消息,那肯定要考虑会不会重复消费?能不能避免重复消费?或者重复消费了也别造成系统异常可以吗?这个是 MQ 领域的基本问题,其实本质上还是问你使用消息队列如何保证幂等性,这个是你架构里要考虑的一个问题。 面试题剖析 回答这个问题,首先你别听到重复消息这个事儿,就一无所知吧,你先大概说一说可能会有哪些重复消费的问题。 首先,比如 RabbitMQ、RocketMQ、Kafka,都有可能会出现消息重复消费的问题,正常。因为这问题通常不是 MQ 自己保证的,是由我们开发来保证的。挑一个 Kafka 来举个例子,说说怎么重复消费吧。 Kafka 实际上有个 offset 的概念,就是每个消息写进去,都有一个 offset,代表消息的序号,然后 consumer 消费了数据之后,每隔一段时间(定时定期),会把自己消费过的消息的 offset 提交一下,表示“我已经消费过了,下次我要是重启啥的,你就让我继续从上次消费到的 offset 来继续消费吧”。 但是凡事总有意外,比如我们之前生产经常遇到的,就是你有时候重启系统,看你怎么重启了,如果碰到点着急的,直接 kill 进程了,再重启。这会导致 consumer 有些消息处理了,但是没来得及提交 offset,尴尬了。重启之后,少数消息会再次消费一次。 举个栗子。 有这么个场景。数据 1/2/3 依次进入 kafka,kafka 会给这三条数据每条分配一个 offset,代表这条数据的序号,我们就假设分配的 offset 依次是 152/153/154。消费者从 kafka 去消费的时候,也是按照这个顺序去消费。假如当消费者消费了 offset=153 的这条数据,刚准备去提交 offset 到 zookeeper,此时消费者进程被重启了。那么此时消费过的数据 1/2 的 offset 并没有提交,kafka 也就不知道你已经消费了 offset=153 这条数据。那么重启之后,消费者会找 kafka 说,嘿,哥儿们,你给我接着把上次我消费到的那个地方后面的数据继续给我传递过来。由于之前的 offset 没有提交成功,那么数据 1/2 会再次传过来,如果此时消费者没有去重的话,那么就会导致重复消费。 如果消费者干的事儿是拿一条数据就往数据库里写一条,会导致说,你可能就把数据 1/2 在数据库里插入了 2 次,那么数据就错啦。 其实重复消费不可怕,可怕的是你没考虑到重复消费之后,怎么保证幂等性。 举个例子吧。假设你有个系统,消费一条消息就往数据库里插入一条数据,要是你一个消息重复两次,你不就插入了两条,这数据不就错了?但是你要是消费到第二次的时候,自己判断一下是否已经消费过了,若是就直接扔了,这样不就保留了一条数据,从而保证了数据的正确性。 一条数据重复出现两次,数据库里就只有一条数据,这就保证了系统的幂等性。 幂等性,通俗点说,就一个数据,或者一个请求,给你重复来多次,你得确保对应的数据是不会改变的,不能出错。 所以第二个问题来了,怎么保证消息队列消费的幂等性? 其实还是得结合业务来思考,我这里给几个思路: 比如你拿个数据要写库,你先根据主键查一下,如果这数据都有了,你就别插入了,update 一下好吧。比如你是写 Redis,那没问题了,反正每次都是 set,天然幂等性。比如你不是上面两个场景,那做的稍微复杂一点,你需要让生产者发送每条数据的时候,里面加一个全局唯一的 id,类似订单 id 之类的东西,然后你这里消费到了之后,先根据这个 id 去比如 Redis 里查一下,之前消费过吗?如果没有消费过,你就处理,然后这个 id 写 Redis。如果消费过了,那你就别处理了,保证别重复处理相同的消息即可。比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了,重复数据插入只会报错,不会导致数据库中出现脏数据。 当然,如何保证 MQ 的消费是幂等性的,需要结合具体的业务来看。 往期回顾: 【Java问答学堂】1期 为什么使用消息队列?消息队列有什么优点和缺点?Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景? 【Java问答学堂】2期 如何保证消息队列的高可用? 【Java问答学堂】3期 如何保证消息不被重复消费?或者说,如何保证消息消费的幂等性? 【Java问答学堂】4期 如何保证消息的可靠性传输?(如何处理消息丢失的问题?) 【Java问答学堂】5期 如何保证消息的顺序性? 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题? 【Java问答学堂】7期 如果让你写一个消息队列,该如何进行架构设计? 【Java问答学堂】8期 es 的分布式架构原理能说一下么(es 是如何实现分布式的啊)? 【Java问答学堂】9期 es 写入数据的工作原理是什么啊?es 查询数据的工作原理是什么啊? 【Java问答学堂】10期 es 在数据量很大的情况下(数十亿级别)如何提高查询效率啊? 【Java问答学堂】11期 es 生产集群的部署架构是什么?每个索引的数据量大概有多少? 【Java问答学堂】12期 项目中缓存是如何使用的?为什么要用缓存?缓存使用不当会造成什么后果? 【Java问答学堂】13期 redis 和 memcached 有什么区别? 【Java问答学堂】14期 redis 都有哪些数据类型?分别在哪些场景下使用比较合适? 【Java问答学堂】15期redis 的过期策略都有哪些?内存淘汰机制都有哪些? 【Java问答学堂】16期如何保证 redis 的高并发和高可用?redis 的主从复制原理能介绍 为什么使用消息队列?【Java问答学堂】17期 消息队列有什么优点和缺点?【Java问答学堂】18期 Kafka、ActiveMQ、RabbitMQ、RocketMQ的区别?【Java问答学堂】19期 如何保证消息队列的高可用?【Java问答学堂】20期

剑曼红尘 2020-05-19 13:11:25 0 浏览量 回答数 0

问题

如何保证消息不被重复消费?或者说,如何保证消息消费的幂等性?【Java问答学堂】21期

剑曼红尘 2020-05-19 13:11:17 0 浏览量 回答数 1

问题

ES 写入数据的工作原理是什么啊?ES 查询数据的工作原理是什么啊?【Java问答学堂】27期

剑曼红尘 2020-05-27 20:28:45 22 浏览量 回答数 1

回答

怎么 没人来呀 @中山野鬼###### 1、如果想去掉while(true),可以考虑通知实现; 2、关于自动重连的问题,可以考虑重发送逻辑中抽离出来,采用心跳检测完成; 3、另外发送速率统计部分也应该抽离出来。 4、上多通道要考虑资源使用可控。 5、实在不行按照业务拆分成多模块,用redis 或mq类的扩展一下架构设计; ######回复 @OS小小小 : map =(Map)JSONObject.parse(SendMsgCMPP2ThredPoolByDB.ZhangYi.take()); 换成take,阻塞线程,试试。######回复 @OS小小小 : 1、通知只是告知队列里有新的数据需要处理了; 5、内存队列换成redis队列 实现成本增加,但是可扩展性增加;######1、通知实现的话 ,岂不是 无法保证 最少发送么,又会陷入另一个问题中 是吗? 或者是我的想法不对么? 2、嗯,这一块可以这样做。谢谢你 3、速率统计这里 我目前想不到怎么抽离、既可以控制到位,又可以保证不影响。。。 5、redis 是有的 但是 redis的队列的话 跟我这个 没啥区别吧,可能速度更快一点。######while(true) 里面 没数据最起码要休眠啊,不停死循环操作,又没有休眠cpu不高才怪######回复 @OS小小小 : 休眠是必须的,只是前面有数据进来,可以用wait notify 的思路通知,思路就是这样,CountDownLatch 之类多线程通讯也可以实现有数据来就能立即处理的功能######嗯,目前在测试 排除没有数据的情况,所以这一块没有去让他休眠,后面会加进去。 就针对于目前这种情况,有啥好办法吗###### 我的思路是:一个主线程,多个任务子线程。 主线程有一层while(true),这个循环是不断的扫描LinkedBlockingQueue是否有数据,有则交个任务子线程(也就是你这里定义的线程池)处理,而不是像你这样每个子任务线程都有一个while(true) ######这才是对的做法######嗯,这思路可以。谢谢哈###### 引用来自“K袁”的评论 我的思路是:一个主线程,多个任务子线程。 主线程有一层while(true),这个循环是不断的扫描LinkedBlockingQueue是否有数据,有则交个任务子线程(也就是你这里定义的线程池)处理,而不是像你这样每个子任务线程都有一个while(true) 正确做法. 还有就是 LinkedBlockingQueue 本身阻塞的,while(true)没问题,主要在于不需要每个发送线程都去block######while(true)不加休眠就会这样###### java 的线程数量大致要和cpu数量一致,并不是越多越快,线程调度是很消耗时间的。要用好多线程,就需要设计出好的多线程业务模型,不恰当的sleep和block是性能的噩梦。利用好LinkedBlockingQueue,队列空闲时读队列的线程会释放cpu。利用消息触发后续线程工作,就没必要使用while(true)来不停的扫描。 ######@蓝水晶飞机 看到你要比牛逼,我就没有兴趣跟你说话了######回复 @不日小鸡 : 我就是装逼怎么啦,特么的装逼装出样子来的,起码也比你牛逼啊。######回复 @蓝水晶飞机 : 你说这话不能掩盖你没有回复我的问题又来回复我导致装逼失败的事实。 那你不是楼主你回复我干什么,还不是回答我的问题。 不要装逼了好么,装多就成傻逼了######回复 @不日小鸡 : 此贴楼主不是你,装什么逼。######回复 @王斌_ : 这些我都知道,我的意思是你这样回复可能会误导其他看帖子的人或者新手,让他们以为线程数就等于CPU数###### 引用来自“OS小小小”的评论 怎么 没人来呀 @中山野鬼 抬举我了。c++ 我还敢对不知深浅的人说,“权当我不懂”,java真心只是学过,没有实际工程上的经验。哈。而且我是c的思维,面对c适合的应用开发,是反对使用线程的。基本思维是,执行模块的生命周期不以任务为决定,同类的执行模块,可根据物理硬核数量,形成对应独立多个进程,但绝对不会同类的任务独立对应多个线程。哈。所以java这类面向线程的设计,没办法参与讨论。设计应用目标不同,系统组织策略自然有异。 唯一的建议是:永远不要依赖工具,特别是所谓的垃圾资源处理回收机制,无论它做的再好,一旦你依赖,必然你的代码,在不久的将来会因为系统设计规模的变大,而变的垃圾。哈。 听不懂的随便喷,希望听懂的,能记得这个观点,这不是我一个人的观点。 ######给100万像素做插值运算进行染色特效,请问单线程怎么做比多线程快?###### @乌龟壳 : 几种方法都可以,第一是按照计算步骤,每个进程处理一个步骤,然后切换共享空间(这没有数据传递逻辑上的额外开销),就是流水思维。第二个是block的思维,同样的几个进程负责相同计算,但负责不同片区。同时存在另一类的进程是对前期并发处理完的工作进行边界处理。 你这个例子体现不出进程和线程的差异的。 如果非要考虑进程和线程在片内cache的差异,如果没记错(错了大家纠正哈),进程之间的共享是在二级缓存之间吧。即便线程能做到一级缓存之间的共享,但对于这种大批量像素的计算,用进程仍然是使用 dma,将数据成块载入一级缓存区域进行处理,而这个载入工作和计算工作是同步的。不会有额外太多的延迟。 你举的这个例子,还真好是我以前的老本行。再说了。像素计算,如今都用专用计算处理器了吧。还用x86或arm来处理,不累死啊。哈。 而且这种东西java不适合,同样的处理器,用c写,基本可以比java快1到2倍。因为c可以直接根据硬件特性和计算逻辑特点有效调度底层硬件驱动方式。而java即便你用了底层优化的官方库,仍然不能保证硬件与计算目标特性的高度整合。 ######回复 @中山野鬼 : 简单来说,你的多个进程处理结果进行汇总的时候,是不是要做内存复制操作?如果是多线程天然就不用,多进程用系统的共享内存机制也不用,问题是既然用了共享内存,和多线程就没区别了。######回复 @乌龟壳 : 两回事哦。共享空间是独立的,而线程如果我没记错,全局变量,包括文件内的(静态变量)是共享的。不同线程共享同一个进程内的变量嘛。这些和业务逻辑相关的东西,每个线程又是独立一套业务逻辑,针对c语言,这样去设计,不是没事找事嘛。面向对象语言,这块都帮你处理好了,自然没有关系。######既然有共享空间了,那你所说的进程和线程实际就是一回事了。###### @乌龟壳   ,数据分两种,一种和算法或处理相关的。一种是待处理的数据。 前者,不应该共享,后者属于数据加工流程,必然存在数据传递或流动,最低成本的传递/流动方式就是共享内存,交替使用权限的思路。 但这仅仅针对待加工的数据和辅助信息,而不针对程序本身。 进程不会搞混乱这些东西特别是(待加工数据的辅助信息),而线程,就各种乱吧。哈。 进程之间,虽然用共享空间,但它本质是数据传递/流动,当你采用多机(物理机器)并发处理时,进程移动到另外一个物理主机,则共享空间就是不能选择的传递/流动方式了。但线程就没有这些概念。 ######回复 @中山野鬼 : 是啊,java天然就不是像C一样对汇编的包装。######@乌龟壳 面向企业级的各种业务,java这些没问题的。而且更有优势,面向计算设备特性的设计开发,就不行了。哈。######回复 @中山野鬼 : 也算各有场景吧,java同样可以多进程可以分布式来降低多线程的风险。java也可以静态编译成目标机器码。总之事在人为。######回复 @乌龟壳 : 高手,啥都可以,低手,依赖这些,就是各种想当然。哈哈。######回复 @中山野鬼 : 那针对java的垃圾回收,这个东西是可以调节它算法的,不算依赖工具吧,哈。不然依赖C语言语法也算依赖工具咯。哈。;-p

kun坤 2020-05-31 13:04:51 0 浏览量 回答数 0

问题

MaxCompute百问集锦

yq传送门 2019-12-01 20:16:47 2404 浏览量 回答数 1

回答

"三个字,不可能######回复 <a href=""http://my.oschina.net/hanke"" class=""referer"" target=""_blank"">@DanceCoder : 没有这种数据库管理员,如果是系统里的管理员,倒是可以通过系统代码,实现管理员只能管理不能查看的逻辑。数据库本身的管理员不行,除非让数据库管理员都进不了数据库,那还管理啥。######回复 <a href=""http://my.oschina.net/visualgui823"" class=""referer"" target=""_blank"">@乌龟壳 : 面试官说可以执行增删改查,就是直接在控制台执行SQL语句的那种。######回复 <a href=""http://my.oschina.net/hanke"" class=""referer"" target=""_blank"">@HankeBoom : 如果有背景就可能不一样,比如说的其实是所谓的数据库管理员之类的,就看看服务器状态那些,数据库都没权限进去######哈哈哈,面试官好坏。。。。。######你确认他不是在出脑筋急转弯? ######不知道,根据我仅有的面试经验,一般都是先问一些基础的问题。我也不知道他为什么问这么摸不着头脑的问题。难道是在考察我的解决问题能力?######<span style=""color:#444444;font-family:'Microsoft YaHei', Verdana, sans-serif, 宋体;font-size:14px;line-height:normal;background-color:#FFFFFF;""> 数据库管理员没有权限看数据库,感觉就像厨师不能进厨房一样。######面试官的意思是不要在管理员权限方面限制不同权限级别的管理员###### 在java程序是对用户名和密码进行了加密后存入数据库的,登录的时候时候再提取数据库的数据进行相反的解密过程,如果一致,才通过 根据你的描述,管理员A又可以管理服务器后台,又可以管理数据库,那只能说明管理员只能为一个(多了就权责不分了),当然最好的是 不要给A日志信息查看权限,要不然就他就可以做到天衣无缝。 以上是个人对数据安全性的理解 下面废话:1:不考虑数据库权限、不考虑加密、不考虑数据库类型,说明数据库安全性有问题。2:面试官的回答“登录修改用户密码和然后就可以登录了。” ,有点sb思维,我都看得到密码了,还用修改后台的密码,还要脱裤子放屁(多此一举) ######哈哈哈,面试官确实好坏###### 这种东西只有在登录的时候处理吧. 数据库都是持久性的东西, 不管如何加密. 只要修改成一个我知道的明文加密的数据不就行了? 所以,还是在登录的后台做处理. 比如加密的是根据用户输入的密码加上用户名之类的处理过的密码. 那么数据库管理员不知道后台的处理逻辑, 修改了数据库也无用. ######长知识了,谢谢######66666###### 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 ######就是性能堪忧######这个有点厉害啊###### 引用来自“cys1357”的评论 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 可是都说了不允许加密了,实在想不出不加密怎么办了######你需要了解MySQL的“视图”是干嘛的。。。。。。。######视图不是也可以执行改数据操作吗###### 引用来自“cys1357”的评论 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 引用来自“钛元素”的评论可是都说了不允许加密了,实在想不出不加密怎么办了 上面的加密只是为了去掉多个片段记录中用户名的相关性,让管理员无法通过搜索找出所有和这个用户名相关的记录项,不需要解密,只是一种变换算法。 "

montos 2020-06-04 16:18:47 0 浏览量 回答数 0

回答

"三个字,不可能######回复 <a href=""http://my.oschina.net/hanke"" class=""referer"" target=""_blank"">@DanceCoder : 没有这种数据库管理员,如果是系统里的管理员,倒是可以通过系统代码,实现管理员只能管理不能查看的逻辑。数据库本身的管理员不行,除非让数据库管理员都进不了数据库,那还管理啥。######回复 <a href=""http://my.oschina.net/visualgui823"" class=""referer"" target=""_blank"">@乌龟壳 : 面试官说可以执行增删改查,就是直接在控制台执行SQL语句的那种。######回复 <a href=""http://my.oschina.net/hanke"" class=""referer"" target=""_blank"">@HankeBoom : 如果有背景就可能不一样,比如说的其实是所谓的数据库管理员之类的,就看看服务器状态那些,数据库都没权限进去######哈哈哈,面试官好坏。。。。。######你确认他不是在出脑筋急转弯? ######不知道,根据我仅有的面试经验,一般都是先问一些基础的问题。我也不知道他为什么问这么摸不着头脑的问题。难道是在考察我的解决问题能力?######<span style=""color:#444444;font-family:'Microsoft YaHei', Verdana, sans-serif, 宋体;font-size:14px;line-height:normal;background-color:#FFFFFF;""> 数据库管理员没有权限看数据库,感觉就像厨师不能进厨房一样。######面试官的意思是不要在管理员权限方面限制不同权限级别的管理员###### 在java程序是对用户名和密码进行了加密后存入数据库的,登录的时候时候再提取数据库的数据进行相反的解密过程,如果一致,才通过 根据你的描述,管理员A又可以管理服务器后台,又可以管理数据库,那只能说明管理员只能为一个(多了就权责不分了),当然最好的是 不要给A日志信息查看权限,要不然就他就可以做到天衣无缝。 以上是个人对数据安全性的理解 下面废话:1:不考虑数据库权限、不考虑加密、不考虑数据库类型,说明数据库安全性有问题。2:面试官的回答“登录修改用户密码和然后就可以登录了。” ,有点sb思维,我都看得到密码了,还用修改后台的密码,还要脱裤子放屁(多此一举) ######哈哈哈,面试官确实好坏###### 这种东西只有在登录的时候处理吧. 数据库都是持久性的东西, 不管如何加密. 只要修改成一个我知道的明文加密的数据不就行了? 所以,还是在登录的后台做处理. 比如加密的是根据用户输入的密码加上用户名之类的处理过的密码. 那么数据库管理员不知道后台的处理逻辑, 修改了数据库也无用. ######长知识了,谢谢######66666###### 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 ######就是性能堪忧######这个有点厉害啊###### 引用来自“cys1357”的评论 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 可是都说了不允许加密了,实在想不出不加密怎么办了######你需要了解MySQL的“视图”是干嘛的。。。。。。。######视图不是也可以执行改数据操作吗###### 引用来自“cys1357”的评论 看看是否可以这样做 用户的相关信息只通过uuid来查询,并且所有信息与用户名无相关性。用户名和uuid的对应关系拆分成多个记录保存,比如用户名abc ,uuid 123-456-789-012-234 保存成加密后的记录 cde asd ghi fdfd jkl rrr mno !3e pqr rwq 这里第一列是abc加上序号 变成的abc1,abc2...再加密后的字符串,第二列是uuid片段加密后的数据, 客户端通过多次请求再解密获取完整的uuid,然后获取数据,这样除非管理员能解密否则无法获得完整数据 引用来自“钛元素”的评论可是都说了不允许加密了,实在想不出不加密怎么办了 上面的加密只是为了去掉多个片段记录中用户名的相关性,让管理员无法通过搜索找出所有和这个用户名相关的记录项,不需要解密,只是一种变换算法。 "

montos 2020-06-04 16:18:39 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站