• 关于 业务管理点可以干啥 的搜索结果

回答

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

问题

SSH面试题

琴瑟 2019-12-01 21:46:22 3489 浏览量 回答数 0

回答

我是A######回复 @aa小马 : 你把活分给别人去做,发现才是头疼要死。 你的需求,下面的人出bug了,调不出来了,干不动了,你恨不得冲上去把他踢开自己上,那才觉得累啊######回复 @aa小马 : 可笑至极,你以为写代码是最累的?你以为任务分下去就轻松了?很多时候,一个主管要做的事非常多,如果事情不分下去,主管就连累的牛马都不如了,你视野要放宽点,殊不知多少主管不是想安安静静写代码,什么乱七八糟的事情都不用管多好,工资低点,但是时薪高,等你当上主管试试你就明白了,哦,鉴于你现在的态度和视野,不改变的话,估计不会有机会了。######还真有你这一类人,你现在是不是过的非常爽,有活自己过问一下,就分给别人了。自己也不写代码######同事A  给了 同事B 很好的锻炼机会,独立完成项目指日可待!终有一天也成为 A!...这种事情我一开始都会给b说清楚, 愿跟着我敲,就敲,不愿跟了也可以推荐给其他人,,,记得之前带了一个妹子,带了两个周,然后想换个人带,跟我说想让我师兄带,(我师兄技术很牛逼,帅气且单身)....然后带了一个周,,,,被请辞了....原因:太烦太菜...什么**问题都问!说话也不过脑子................ ######我也很傻很天真,头像是个美女,我就是为了自己看着爽,在这里随便发个帖子都能叼到一堆饿狼######只能说你太傻太天真,你不想想周末带去哪里了?######我的同事也是A 然后看着他一周要三份加起来差不多200多页 页页写满的文档。。我就感觉写代码真幸福了。。######是的,深有体会,宁愿去跟着别人写代码,轻轻松松,技术到位根本就不用发愁,操那闲心干啥,连生活都的为工作让步。######能管好小弟就是好A,现在公司更看重管理而非coding能力######想那么多干嘛,多干多学,把公司的东西搞得牛逼一些,让别的同事接不住 ,然后拍屁股走人,跳个牛逼的公司,留下这家公司傻逼程序员一句代码都看不懂——######回复 @Moses_Fu : 那可不一定,闲来没事,写写IL也是可以的,效率还高。别要以为自己所有代码你都看得懂,牛逼的代码你看不懂的多了去了。还有,不要以为你这样纠结说表明你能写出一份优质的别人又能看得懂的代码,然后你是大牛一样,看看楼主的题目,是帮楼主解决问题的,不是给你显摆的。######回复 @MZHS : 说的是报复好么,公司挤兑你,你难过,你走的想法都有了,还想着写所有人能看得懂的品优质良的代码,难道是楼主活该被人挤兑么?你这个话不对题啊,看好楼主问什么好么?######本来一张表搞定的事情,分成4张半,看谁还接得住######回复 @暗影灰蝶 : 代码这个东西就是给人看的,不是写的晦涩才是技术高,是写的简单,功能又实现了,别人一看,唉吆,我咱就想不到这样实现!这才是技术。自己写的东西别人看不懂你只适合一个人开发。######回复 @暗影灰蝶 : 故意或者没能力把代码的思想写得易懂,还能怪别人能力不足,这锅甩的好。c++代码比较繁复没错,但不代表写的人没办法将业务思想体现出来;c#、java的GC多不需要开发去操心,即使涉及到effective programming也不应该成为写出一坨没人看得懂的代码。######  这种问题。你现在是B。。以后也会当A。   大多都是这样过来的。 ###### 1、同事A的作为是他自身的事情,你不可能指望着别人怎样,而且领导是只看项目结构,并不看这个项目同事A或者同事B是否都写了代码; 2、同事B的心态有点不对,同事A作为直属的带领人,是有权给你分配任务的,并且也不是需要每件事都要经过领导传达给同事A后,再传达给同事B来彰显同事A的作用,这个明显是同事B自身的心态问题,浮躁了; 3、同事B觉得自己在这个公司里,对于业务、对于项目应用技能都掌握了,可以独当一面了,是可以绕开A去跟领导去交流,以期获得更大的倚重,这个过程需要技巧,而且最好也不要得罪A,如果领导不赏识,你可以很欣然的离职,如果赏识你不就可以往上走了嘛,而且还能比较好的处理同事关系。 整个过程B的心态和认知定位有很大问题,需要调整,不然去哪个公司都一样,跳来跳去,终究没有归属感! ######不知道 伊人枫 是不是过来人。有些事情当局者迷,旁观者清啊,看不透,就是好多事情都从自己出发,以后还要多些大局观,想问题全面点######恩,你说的有道理。职场的规则,职业人的素养。有时能不能成为职场成功的人,这些情商上面的东西还是很重要的,有的人技术能力有,表达能力,领导能力跟不上,也当不了头儿。######可能a做了很多你不了解,而且目前你还无法胜任的工作,说白了,就算是it公司,编码也只是公司运营中的一小部分。思考,团队的运转,发展方向和策略,比成熟团队的编码更是脑力活######确实是这样的,技术的头,很多时候没有写具体的代码,但是遇到问题下面的人要不就是经验不够,能解决但是方案效率很差,或者就没头绪,最后都要自己上公关下来,搞出 Demo 等,然后下面的改或者照着样子做,还要操心各种事,没到这个位置的绝对想象不到你做了多少事,就像你不知道你们董事长做了多少事,以为他天天就是和别人喝茶聊天扯蛋###### 是个人都会有B同事的想法,但是这样想有什么用呢! 要么走要么忍,谁让是A招来的呢,制度不行的公司扯什么都没用 ######没办法,公司的制度就是如此

kun坤 2020-06-09 15:33:01 0 浏览量 回答数 0

新用户福利专场,云服务器ECS低至102元/年

新用户专场,1核2G 102元/年起,2核4G 699.8元/年起

问题

MaxCompute百问集锦

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

回答

转自DT财经 ,作者陷入焦虑的DT君 前两周播出的《明星大侦探—MGQ时尚风云》中,节目组设计了一个与中年危机相关的案件: 撒贝宁在这期节目中饰演一位40岁“上有老,下有狗”的杂志社时装编辑,虽然月入12w,但是每个月刨去房贷、车贷、儿子补习班费用、父母医疗保健费用以及各种家庭开支后,只能剩下1块钱。被主编无理辞退后,他由于年龄过大而迟迟找不到新工作,在家庭经济重担的支配下,对老板心生杀机…… 节目中的设定确实有些夸张,但剧本却是来源于真实生活的情绪。2019年“太南了”的一系列感叹中,充满了中年职场人的辛酸与苦涩。 微博上#35岁以上职场人去了哪儿#、#35岁定律#等话题屡屡冲上热搜,随便就能收获近亿的阅读量,知乎、朋友圈、头条……到处充斥着怎么应对35岁危机的回答和文章,“35岁危机”俨然已经成为一个大家公认的专有名词。 (图片说明:百度百科收录的“35岁危机”词条) 这让还未到35岁的小编,内心多少有些焦虑:35岁的职场人就业真有这么难吗?他们都面临着怎样的中年危机?难道除了卖保险,真的就无处可去了吗? DT财经联合智联招聘共同做了个小研究,通过招聘方与应聘者的数据,来看看35岁职场人真实的生存情况。 35岁真的很难吗? 首先,我们想知道,35岁真的面临一个更残酷的世界吗? 从人口结构的大盘面粗略判断,当代中年所面临的竞争,其实并不如他们的前辈或后辈那样激烈。 根据2010年国家第六次人口普查数据,到2019年我国34-43岁的中年人口数量为1.98亿,而44-53岁人口数量为2.42亿,24-33岁人口数量为2.27亿。 也就是说,不管是曾经的,还是未来的中年人,都比现在叫嚷着中年危机的劳动力数量旺盛不少,而他们所面临的,可并不是高速发展的黄金十年。 既然如此,为什么35岁危机的话题一直不绝于耳呢? 招聘方对岗位需求的描述,一定程度上能反映出职场的变幻风向。 从招聘需求来看,2019年第三季度所有的招聘岗位中,只有5%明确要求求职者的年龄低于35岁。 这个看起来并不高的比例,可能并不能完全说明市场的真实需求情况,毕竟从大家的日常吐槽和我们的小范围调研来看,许多公司对年龄的苛刻要求很多时候秉持着只干不说的原则,并不会明晃晃地写在岗位简介里。 但我们注意到一个变化趋势,明确要求求职者35岁以下的岗位比例,与两年前相比上涨了2个百分点,涨幅其实挺大的(60%)。这事实上表明,35岁职场人面临的境遇,确实是比两年前更难了些。 以这5%要求35岁以下的招聘职位作为研究样本,我们大致研究了下不同地方对中年职场人的友好度。 在各类企业中,要求35岁以下的职位比例最高的是国企,而民营公司在岗位要求中对35岁的求职者其实相对温和。 而从公司规模来看,规模越大的公司,要求35岁以下的职位比例就越高。10000人以上的超大公司在2017年就已超过6%;500-999人肩部大公司在两年前的比例还仅有2.1%,但两年间提高了近4个百分点至6%。 哪些行业更看重35岁的年龄线? 要求35岁以下的职位比例越来越高,其实与就业大环境和新兴行业的发展有关。 Linda在一家大数据创业公司做HR,她告诉小编:“这两年在招人的时候确实会优先选择35岁以下,甚至是30岁以下的年轻人,尤其是18年的裁员潮过后,大家其实都不好过。一般达到35岁的职场人在公司都担任比较重要的职务,而我们大数据属于新兴行业,公司的业务变化很快,在探索阶段并不需要那么多指挥官,我们更需要富有创造力、行动力强听指挥的战士。” Linda的话意味着,是否能在35岁前找到一家托付终身的企业至关重要。 可是,在35岁就找到能够让自己奋斗一生的公司,就和20岁就找到长相厮守的老伴一样不靠谱。这时候,选对行业很关键。 小编整理了2019年招聘需求中要求35岁以下职位比例最高和最低的行业。 我们发现,在众多行业中,银行、外包服务、中介服务、保险和通信行业对年龄的限制最大。也就是说,这些行业中有相对更多的岗位只需要年轻力壮的劳动力。 但也有计算机行业、检验检测、IT服务、学术科研和教育培训等行业,在招聘需求中对35岁以上的职场人相对比较宽容。 如果看一下这些行业给大家的固有印象,我们可以认为,在招聘中更看重35岁年龄线的行业,多属于大家印象中的传统行业;而在要求35岁以下职位比例最低的队伍中,新兴行业的比例会更高些。 从岗位来看,商超、保健、银行、房地产、社区等技术门槛较低的基础类岗位,在招聘中要求35岁以下的职位比例最高。 总结下来就是,工作内容更简单或对知识性技能要求更低的岗位,会更偏爱年轻人,毕竟人到中年,精力和体力都无法和年轻人相比。对于用人单位来说,与其去招一个成本更高的中年员工,不如多招几个应届大学生,年轻力壮,生产力更强。 而要求35岁以下职位比例最低的10个岗位中,IT、软件、硬件开发、IT管理、互联网产品、IT运维等互联网/技术岗位占去了大半,这都是对专业技术、创新性要求更高的行业岗位。至少从招聘需求来看,他们并不会太多强调年龄。 显然,这与我们的日常感受并不一致。 35岁话题中最常被吐槽的,恰好是这些不那么强调年龄的岗位从业者,而那些在招聘需求中有更多年龄限制的岗位,存在感并不太强。 这到底是为啥? 为什么35岁的你觉得“太南了” 我们需要明确的是,一个行业或岗位对年龄的限制少,并不意味着中年的求职者就会获得青睐。 35岁求职者的优势在于有更多经验与技能积累,而劣势在于体力和精力不够充沛,只有在更需要经验而非体力的岗位,中年职场人才会有更强的竞争力。 即使我们默认那些并没有对35岁划线的岗位都不需要干体力活,也并不意味着在这些岗位上,经验、积累和阅历就会有比较大的增值效果——如果年龄buff不能增效,用人单位自然会聘请更年轻、薪资要求更低的求职者。 所以,关键点在于,中年职场人是否进入了自己具备优势的行业。 根据智联招聘2019年第三季度的数据,互联网、房地产、教育培训、专业服务、计算机软件等行业,挤下了最多的35岁及以上求职者,而行政/后勤、销售业务、财务/审计/税务、人力资源和软件/互联网开发/系统集成等则是他们投递最多的职位。 我们计算了各个行业和岗位中简历投递数量与最终录用数量的比值,命名为竞争指数,以此来衡量应聘竞争的激烈程度。 我们发现,互联网、房地产、计算机软件、IT服务的行业竞争都格外激烈,而从职位来看,软件/互联网开发/系统集成的竞争指数更是一骑绝尘,97个人参与摸奖,只有1个人能获得offer,另外财务/审计/税务、人力资源、行政等职位的竞争指数也挺高。 这就意味着,上述岗位中,中年职场人不仅要和同龄人竞争,还要和年轻人竞争。 那么,在这些岗位中,中年职场人能获得年龄加成从而脱颖而出吗? 我们统计了各个职位要求工作经验10年以上的岗位数量,数量排名越靠前,则意味着这个职位对经验和阅历的需求度就更高,中年职场人也就相对更有优势。 从结果来看,要求工作经验10年以上岗位数量最多的职位主要可以分为两类,一类是管理向的,包括占比最多的高级管理,以及销售管理、生产管理、项目管理、质量管理等各类管理岗;一类是专业向的,包括土木建筑、财务审计、医院医疗、机械设计等等。 前面提到的竞争激烈的财务/审计/税务、人力资源和房地产相关职位,对工作经验的需求度都排在前列,中年职场人在这些赛道上握着更多本钱。 但相信你也注意到了,挤满了35岁以上求职者的互联网/IT/技术相关职位中,对于工作经验的需求度并没有那么高。虽然这是个典型的高薪赛道,但年龄并不会给中年求职者带来加成效果,如果薪资要求还比较高,实在很难竞争得过除了经验、什么都有的年轻人。 我们总结上述分析,被35岁危机困扰的核心问题可能在于,“理想”的薪资和岗位期望与“现实”竞争力存在分歧,而互联网、IT服务、计算机软件等行业的分歧更为严重。 38岁的陈斌曾经在一家互联网公司做新媒体运营,现在和朋友经营一家外贸公司,他也认同有些中年求职者理想与现实不匹配的问题:“见识过各行各业形形色色的中年求职者,他们对薪资的要求都很高,但被问到有什么核心竞争力的时候,又讲不出个所以然,对自己的未来也没有什么明确的规划。” 同样经历过35岁的他,认为并不存在什么35岁危机,没有能力每个年龄段其实都有危机:“足球运动员到了30岁一般都要大幅降薪,我觉得35岁的普通职场人应该要接受这个事实。你不接受,社会的毒打会让你清醒的。勿骄勿躁,努力提升自己,同时做好期望管理,少听媒体瞎bb。” 这话说得挺残酷,但从“35岁危机”中脱困的最好办法,确实是找到问题根本那个“理想”与“现实”的差距,实实在在地缩短它。 当然,对于已经有了家庭羁绊、要努力维持生活品质的中年人,这又是另外一个要不断感叹“太南了”的过程。 写到这里,我们突然想用《黄金时代》里的一段话作为结尾: “那一天我二十一岁,在我一生的黄金时代。我有好多奢望。我想爱,想吃,还想在一瞬间变成天上半明半暗的云。后来我才知道,生活就是个缓慢受锤的过程,人一天天老下去,奢望也一天天消失,最后变得像挨了锤的牛一样。可是我过二十一岁生日时没有预见到这一点。我觉得自己会永远生猛下去,什么也锤不了我。” (应受访者要求,Linda、陈斌为化名)

茶什i 2020-01-15 11:55:56 0 浏览量 回答数 0

问题

MaxCompute百问集锦(持续更新20171011)

隐林 2019-12-01 20:19:23 38430 浏览量 回答数 18

问题

干货分享:DBA专家门诊一期:索引与sql优化问题汇总

xiaofanqie 2019-12-01 21:24:21 74007 浏览量 回答数 38

回答

Re我和iDBCloud登录数据库的故事 11到13年做DBA的时候,最早接触的是iDB,我的理解之所以叫iDB应该是表达我的数据库的含义吧,估计我还是上学的时候就已经有了,目前iDB已经迭代到3.0,明年初会发布4.0,从DBA视角上看iDB就是可以review业务SQL,自动执行线上DDL,业务数据提取的申请和审批,WEB上的数据查询,最近做产品经理后才有机会系统的审视iDB(一个包含研发支撑、安全管控的企业级数据库管理产品),支撑了淘宝、天猫、支付宝(现在叫蚂蚁金服)的研发流程,保障了每年的双十一,但iDB Cloud与iDB不是一个产品,iDB是企业版的数据库管理产品,iDB Cloud则定位于个人版数据管理,相比企业中的流程约束,iDB Cloud更期望给大家提供在约束下的易用性最大化的灵活数据管理服务! ------------------------- Re我和iDBCloud登录数据库的故事 这个月实例信息-实时性能UI改版发布,新版看起来还是比较舒服的!这个我在5元RDS大促时买的,没有跑业务,所以指标都是0,哈哈 实时性能的原型取自阿里DBA团队的传奇(朱旭)之手:orzdba,貌似很久之前已经开源,谷歌下便知! 翻出之前做DBA使用orzdba观察测试机器压测的截图,orzdba是用perl写的,检查项还是蛮多的,比如io吞吐量、rt、主机的load、swap、innodb row、innodb状态,这些是iDB Cloud没有的功能,iDB Cloud通过用户登录账号访问数据库,只能拿到MySQL进程内存中的状态信息,没有权限拿到主机指标,不过innodb相关信息是可以拿到的,但是考虑一般只有DBA才会关注这些细节,所以没开放,不知道大家还会关注什么指标?有没有办法拿到主机的指标? ------------------------- 回5楼ringtail的帖子 刷新页面,类似关闭并重新打开,啥都没了,这个应该是正常的行为,话说为什么要刷新呢,我记得首页性能指标每5分钟自动刷新,即使点击页面上提供的刷新是没啥事的,而实时性能是每4秒更新一行的,还有什么场景要刷洗整个页面是我没想到的吗? ------------------------- 回7楼ringtail的帖子 目前据我所知,真心还做不到刷新不丢iDB Cloud已经打开的选项卡、sql语句和执行结果什么的,现在只能在刷新时加一个“导航确认”,减少手痒式误刷新,哈哈 ------------------------- Re我和iDBCloud登录数据库的故事 翻工单时,发现有人关心使用iDB Cloud是否会收取流量费,我也没搞清楚,于是问了几个同事,终于把场景基本覆盖了,最终结论: 只要你不把你的RDS实例切换成外网(公网)模式的同时再导出或查询数据就不会收取流量费! 由于那几个工单已经关闭,我就在这里回复下大家,希望那几个朋友能看到 ------------------------- 回9楼yzsind的帖子 一定不会辜负领导的期望,努力工作,争取升职加薪,当上总经理,出任ceo,迎娶白富美,想想还有点小激动 ------------------------- 回10楼佩恩六道的帖子 可能文字不好理解整体的流量计费情况,中午用我那小学的美术细胞,完成了一副“巨作”! ------------------------- Re我和iDBCloud登录数据库的故事 刚才看到一个工单(iDB Cloud点击登录无效),这个工单已经处理完毕,但我觉得可以把售后同学的方法和大家分享下! 以后遇到点击登录无效、登录后菜单栏点击无效、页面展示不全,很可能是浏览器兼容设置的问题! 浏览器兼容设置的问题: 1.检查浏览器是否安装了AdBlockPlus(火狐浏览器的一个扩展),用火狐浏览器的用户遇到类似问题要注意这一点 2.IE浏览器的话就调整下兼容性模式(http://jingyan.baidu.com/article/fcb5aff791bb47edaa4a7115.html ),并进入开发者模式再测试下IDB Cloud 如果上述2招还是解决不了,记得留言给我! ------------------------- Re我和iDBCloud登录数据库的故事 今天看工单时发现有个朋友反馈,包含mediumblob类型字段的表在做导出后,导出文件中没有mediumblob类型字段! 其实导出时默认是不会导出BLOB类型字段,但是在导出-高级选项中是可以选择导出BLOB,但是BLOB字段只能以16进制格式导出,试想一个WORD文档或者一首歌曲,16进制导出后,没啥意义! BOLB字段支持WEB界面上传和下载,是原文件呀,哈哈! ------------------------- Re我和iDBCloud登录数据库的故事 未来几天休假,去考驾照 ------------------------- Re我和iDBCloud登录数据库的故事 看工单和论坛中,有用户会抱怨产品不好用,然后就消失了,真的好可惜! 作为产品经理是很想倾听这些抱怨背后的真实想法,期待可以直接对话,无论是功能缺失,还是操作不便,哪怕是使用上的一种感觉或产品散发的味道不对都可以,不求需求,只求对话! ------------------------- Re我和iDBCloud登录数据库的故事 感谢你的关注和支持! 产品说到底不是产品经理个人的,也不是哪个企业的,而是用户的产品,水能载舟亦能覆舟,产品经理和企业只不过在帮用户把需求实现而已,所以我们会一直坚持下去,坚持和用户一起把iDB Cloud做得更好 ------------------------- Re我和iDBCloud登录数据库的故事 最近几天公司感冒发烧的同学很多,我也是坚持了好几天才沦陷的,这是在我记忆中来杭州4年第一次发烧,看来20多年在东北积累的体质终于被消耗殆尽,不过意外收获是在高烧间隔清醒之际对最近自己的所作所为反倒有了一些悔悟,有些是工作上,有些是做人上 ------------------------- 回24楼zhouzhenxing的帖子 可以的,iDB Cloud对RDS公网和私网模式都是支持的! 你可以在RDS控制台-账号管理中 新建你的数据库账号,然后还是在RDS控制台的右上角,点击“登录数据库”就可以进入iDB Cloud了,建议你先自己试着玩玩,有困惑的话我们一同讨论 ------------------------- 回24楼zhouzhenxing的帖子 iDB Cloud在官网上有2个手册,写的比较官方,可能对你用处不大,我其实不太喜欢写什么手册,如果一个产品做的体验不好,只能靠手册来弥补还是有点low,不过我已经在想如何不low了,还是那句话 有困惑的话我们一同讨论 http://help.aliyun.com/doc/view/13526530.html?spm=0.0.0.0.6W7Qx1 http://help.aliyun.com/view/11108238_13861850.html?spm=5176.7224961.1997285473.4.Irtizv ------------------------- Re我和iDBCloud登录数据库的故事 都说在产品上做加法容易,做减法难,我理解无论产品功能还是工作上,给予总会得到别人的喜欢,而要求或收回时会得到对方的负面情绪,因此趋利避害,尽量不做减法,但有时候很难避免,这就要想想为什么要做减法? 多数都是之前错误选择,做了过多的加法,因为普通的加法很好做,人们往往会趋之如骛,但是真正、正确的加法是要在拒绝几十到上百种选择基础上的最终选择,将复杂解决方案以极简形式展现出来,而不是解决方案和功能的堆积,所以未经严格挑选的加法对产品是有害的,工作也一样,不要贸然接受新工作,保证核心精力投入到核心工作上,摊子铺得太大,一定会遇到心力瓶颈,而心力一旦枯竭,再强的脑力也无法施展,任何一项工作都是以大量心力付出为前提,脑力提升我找到了一些办法,心力提升却一筹莫展,所以只好专注,要不全心投入,要不置身事外,今后功能和工作都要适时做做减法了! ------------------------- Re我和iDBCloud登录数据库的故事 今天有个同事转给我一个工单,说从深圳云管理系统界面的iDB Cloud上看到库是utf8,而后端开发人员说库是gbk的,我查看了工单中截图附件(RDS控制台-参数设置),虽然从工单中无法完全断定用户遇到的问题,我还是大胆猜测下: 我看到截图上的character_set_server参数,首先character_set_server是RDS唯一开放的关于字符集的参数,但其实这个参数与用户在iDB Cloud上看到数据是否乱码没有关系,character_set_server其实就是默认的内部操作字符集,只有当字段->表->库都没有设置CHARACTER SET,才会使用character_set_server作为对应字段-表-库的默认字符集! 透露一个秘诀(传男也传女): (1)让你的字段-表-库的字符集都是utf8; (2)在iDB Cloud-命令窗口执行set names utf8;#会将character_set_client、character_set_connection和character_set_results都设置成utf8 只要让(1)和(2)字符集保持一致(utf8、gbk、latin1等),乱码就搞定了! 不清楚为什么截图会变成上面这样!把在iDB Cloud-命令窗口上执行的命令和结果也粘下 mysql>set names gbk; 执行成功,花费 7.59 ms. mysql>show  variables like '%char%'; +--------------------------+----------------------------------+ | Variable_name            | Value                            | +--------------------------+----------------------------------+ | character_set_client     | gbk                              | | character_set_connection | gbk                              | | character_set_database   | gbk                              | | character_set_filesystem | binary                           | | character_set_results    | gbk                              | | character_set_server     | gbk                              | | character_set_system     | utf8                             | | character_sets_dir       | /u01/mysql/share/mysql/charsets/ | +--------------------------+----------------------------------+ 共返回 8 行记录,花费 10.51 ms. mysql>set names utf8; 执行成功,花费 7.32 ms. mysql>show  variables like '%char%'; +--------------------------+----------------------------------+ | Variable_name            | Value                            | +--------------------------+----------------------------------+ | character_set_client     | utf8                             | | character_set_connection | utf8                             | | character_set_database   | gbk                              | | character_set_filesystem | binary                           | | character_set_results    | utf8                             | | character_set_server     | gbk                              | | character_set_system     | utf8                             | | character_sets_dir       | /u01/mysql/share/mysql/charsets/ | +--------------------------+----------------------------------+ 共返回 8 行记录,花费 10.32 ms. ------------------------- Re我和iDBCloud登录数据库的故事 你的专属BUG: 发现时间 资深用户 专属BUG 2015-02-03 23:06 啊啊啊啊8  实例信息-实时性能-参数说明-【delete】 表示InnoDB存储引擎表的写入(删除)记录行数 ------------------------- Re我和iDBCloud登录数据库的故事 用户“夫子然”反馈说iDB Cloud感觉没phpMyAdmin方便! 非常感谢这个用户的反馈,我先谈下我的理解,每个人使用产品都有一些固定的用例(use case),我无法承诺针对任何人的任何用例,都做到最短操作路径(方便),这个用户抛出的问题也是我一直在思考的,虽然无法100%,但是我们可以覆盖主流用例,只要绝大多数的常规操作室是方便的,少数非经常用的操作路径长点,应该能接受吧,我们已经在行动! 今天iDB Cloud发布了2.0.2,一个主要变化就是在左侧对象列表上增加了“列”和“索引”,正是我们分析数据看到在众多数据库对象中表的操作是最频繁的,而在表的操作中“列“和”索引“是最频繁的,这个版本将对“列”和“索引”的操作前置,缩短了主流用例路径,与用户“夫子然”的建议不谋而合,这只是开始,只要我们深挖,与功能和体验死磕,终有一天会让大家说iDB Cloud比phpMyAdmin方便! ------------------------- 回31楼sqlserverdba的帖子 非常感谢! 有你们作为后盾,有用户支持,才有iDB Cloud的现在和未来! ------------------------- 消失了几天,终于把科目三和科目四搞定了,昨天终于拿到驾照了之前在【17楼】总结了科目二的一些体会,今天也分享下科目三的一点点感受! 考试前几天,教练说是智能考(据说智能考比较简单,通过率很高),结果就留出考前2天练车时间,结果阴差阳错的换成了人工考(貌似是我们车是4个大老爷们,听教练说他一年最多抽到2次人工考就算多的啦,对此我只能呵呵),现在的问题就来了,4个人2天练车时间,一个人半天,那就从早到晚的练呗,我先简单描述下整个过程! 1.心态(1)从开始练车到考试通过,心情没有特别大的起伏,不过考前失眠还是有的,哈哈(2)另外三个人,有的信心满满,有的吊儿郎当,有的不言不语,我应该也属于不言不语那种 2.练习(1)4个人轮流练,虽然一天下来很累,但还能挺住,开的时好时坏,不过总体上在变好(2)开车的时候几乎意识不到什么的,关键是在后座自己去琢磨,回忆自己错在哪里,为什么会错 3.考试(1)考试单上说7:00考试,结果在寒风中等了1个小时,终于盼来了考官,一共5辆车考试,我们是第二辆车(2)第一辆车是2男2女,2女都挂,当时我们第二辆车是被要求跟在第一辆车后面的,所以看的一清二楚,比如连续3次手刹未放下导致起步失败、4档走转弯到对向车道等(3)接下来到我们了,4男0女,结果挂了2男(信心满满和吊儿郎当) 上面只是简单介绍了科目三过程,下面才是干货! 每年都有成千上万的人拿到驾照,我不认为自己牛,只是把我个人的应对方法和背后的原因拿出来分享下!练车其实就是教练的心智模型-翻译-语言-反译-我们的心智模型,让我们知道在什么情况做什么动作,预测路况,只要我们关于开车拥有了自己的心智模,开车就变成了一种本能,就像一旦学会了骑自行车,很难失去这种技能,在练车之前,我们是有自己关于开车的心智模型的,正所谓没吃过猪肉也见过猪跑,但是我们想想自己关于开车的心智模型是正确的吗?显然不是,不信你就试试去开车吧,抛开被交警抓之外,我想应该也能开起来,至于开的好不好,会不会一直开得好,我说不准,但是绝大多数人一定是开不好的,所以我们报驾校,除了硬性法律规定,驾校教练的确交会了很多东西,虽然很多是应试的技巧,这里就顺便说下这些技巧,技巧具体内容每家教练都会教的,而我想说的技巧其实就是“语言”,通过教练的“心智模型”-翻译出来的“语言”,接下来我们要做什么,“反译”将教练开车技巧的“语言”理解,首先你要虚心去接受,然后再去观察或运用,根据反馈把坏的放弃,把好的保留以便修正自己关于开车的“心智模型”,而“心智模型”最快速的形成方式就是亲身体验,所以一定要实战、要开车,还要经常开车,不断改进关于开车的“心智模型”,拿3个案例具体说下吧!【吊儿郎当】这两天都是下午才过来练车,开车时教练说一句话,他有十句等着,其中五句是解释自己为什么要这么做,另外五句是在问如果这种情况应该怎么做,如果那种情况怎么做,总是在关注自己想象中的场景,而不关注自己正在体验的场景,所以学来学去还是最初始的关于开车的“心智模型”,失败在“反译”这一步,认为只要听过就会了,结果被考官判直接挂掉并不予补考机会 【信心满满】与我们一直练车,对教练的话言听计从,而且也理解了,如果是上学时的考试或科目三智能考试一定没问题,但是面对人工考,评判是由交警而不是电脑,结果转向时没有观察后视镜,被考官迫停在路中间后开始补考,然后还是转向时没有观察后视镜,在路中间起步,之前学的技巧中没有应对的方法,结果还是挂了,教练也很惋惜,如果说他的失败,败于没有改进自己关于开车的“心智模型”,其实“反译”他做的很好,但是在运用、观察和反馈分析上做的不好,“心智模型”不是统一的标准,一定是个性化的,一定是自己认为是好的反馈、行为积累起来的,也只有“心智模型”才能在任何情况下帮助你做出判断,判断效果就取决于“心智模型”是否成熟,成熟的“心智模型”可以让在紧张、突发等情况下依然做出正确的判断,因为那是一种本能 【我】总说别人不好之处,也谈谈我自己,自然这些都是我事后分析总结的,练车过程中可没有感受到,我做的事情也很简单,就是“反译”和改进我的“心智模型”,“反译”,教练说什么,我就听什么,开车时来不及想,就在后座时在脑中模拟上演之前的场景并不断上演我不断修正的剧本,比如我的离合器总是抬的很快,经常熄火,特别是在路况复杂、指令突然时根本来不及思考如何应对,只能靠本能的时候,往往还是会快速抬离合器,因为我的“心智模型”中就是这么认为的,你可以说是离合器太低、座位太靠后,这些都是理由,如果是理由,那就去解决吧!我是这样做的,强制自己将抬离合器的动作拆成3步,即使不开车时也经常练习,慢慢的就变成了“心智模型”的一部分,自然在任何场景下都不会再出现离合器抬快熄火的情况了,这只是一个细节,其他细节也是类似,慢慢我的“心智模型”就建立起来了,开车技巧是很有用的,关键是你要理解这些技巧是要解决什么问题,你要解决相同问题时的做法是否相同,如果有不同之处是否正确,要去不断验证,如果是正确的,就改进到你的“心智模型”吧! PD不光光是要把产品做好,我认为一个好PD应该能让整个世界变得更好! ------------------------- Re我和iDBCloud登录数据库的故事 近期iDB Cloud将更名:DMS DMS (data management service) 数据管理服务 iDB Cloud从RDS起步,目前已经覆盖包括RDS、ADS、TAE,未来2个月还会覆盖万网和DRDS,同时ECS也开始兼容,“DMS”请各位新老用户,继续支持! ------------------------- Re我和iDBCloud登录数据库的故事 1.使用HTTPS iDB Cloud这个4月份中旬版本就会支持HTTPS,敬请期待! 2.设置账号是否允许登录iDB 3.31 会发布一个版本,这版本其中一个功能就是授权登录,允许实例owner设置该实例是否允许别人访问,允许谁可以访问 有如此心犀相通的用户,夫复何求!!! 还有什么建议? ------------------------- 回38楼pillowsky的帖子 好的,我先逐条对照分析下 ------------------------- Re我和iDBCloud登录数据库的故事 RDS数据库?RDS控制台-账号管理,检查下账号对不对,不行就重置密码 ------------------------- Re我和iDBCloud登录数据库的故事 3.31 DMS(原iDB Cloud) 在RDS上新版本发布! 【实例授权】 DMS for MySQL 2.1发布! 【会话统计】 DMS for SQL Server 2.0发布! 【E-R图】 【对象列表】 ------------------------- Re我和iDBCloud登录数据库的故事 你是想听客服回复?算了,我还是从DMS PD 看RDS的视角来分享下吧! RDS是一个数据库,在数据库之外包装了一些东西,帮用户做了备份恢复、HA、监控等,回到你提到的账号,root账号在MySQL里是权限最大的,也是风险最大的,为了保证RDS这些备份恢复、HA能7*24小时为你服务,所以就不能让你的账号去影响到这些组件,不然你一个误操作把实例关闭了怎么办,但是我承认目前RDS在控制台上提供的账号的确限制比较死,所以在RDS上你是无法获取root账号的,话说你要root权限做什么,你说的数据库创建在RDS控制台上提供功能了 ------------------------- 回46楼苗教授的帖子 客气了,也不知道能不能帮上你! 如果从外看RDS的使用的话,可以在RDS控制台上去管理RDS实例(用用就熟悉了),或者直接调用OPEN API来完成实例管理操作,然后针对RDS实例中数据管理,就可以登录DMS,有几个常用链接发你看看,有问题可以在这里继续探讨! DMS: http://idb.rds.aliyun.com/ DMS 功能介绍: http://docs.aliyun.com/#/rds/getting-started/database-manage&login-database OPEN API: http://docs.aliyun.com/?spm=5176.383715.9.5.1LioEO#/rds/open-api/abstract RDS控制台: https://rds.console.aliyun.com/console/index#/

佩恩六道 2019-12-02 01:21:37 0 浏览量 回答数 0

问题

【精品问答】Java技术1000问(1)

问问小秘 2019-12-01 21:57:43 34170 浏览量 回答数 10
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 SSL证书 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 2020中国云原生 阿里云云栖号