• Smallfly
    2019-02-04
    随着新年的到来,我们的算法专栏也到了尾声。有点怀念那段时间工作不忙,一天能有好几个小时,阅读和思考算法专栏。

    专栏给我带来的收获不仅仅是数据结构和算法的知识。在这之前虽然也每天学习,但总是东一块西一块,没有系统和脉络,一段时间之后,看似学了很多,但并没有什么效果。

    在学习算法课程的过程中,基本都在学习和思考专栏的内容。一般第一天过一遍概念,一边阅读一边手敲。第二天会把重点放在思考上,为什么需要这种数据结构和算法,它的利弊是什么,以及解答思考题。

    真正有收获的是思考和实践而不是阅读,阅读只是表象;如果只是阅读,也没有生字,会很轻松,但效果甚微。

    这让我切身体会到系统和专注的重要性。

    这种经历帮助我在实际工作中解决不少问题,不是说用到了哪种算法,而是在遇到问题时善于花时间去思考解决方案,而不是一味地寻找替代方案,把问题绕过去。

    紧跟着老师的脚步学下来了,不能说都掌握了,但有几点学习的心得想跟大家分享。

    1、迈出第一步。很多事情不是我们不会做,而是不想开始。一想到前面可能会有重重困难,思想上就先败下阵来了。只要开始一点点的弄懂,重在培养兴趣。

    2、慢一点,不贪多。可能有同学落下很多课,看看还有这么多没学,干脆就放弃了。其实并不需要掌握所有的,可以挑选自己感兴趣的内容,细嚼慢咽,先掌握一部分。再从已知探索未知,其实文章之间很多是有关联的,学习过程中可能自个儿就串起来了。

    3、多动手。阅读和思考还是远远不够的,带着文章的思路,用自己熟悉的语言实现一遍,跑起来测一测,会更有成就感,也是自己学习的痕迹。

    虽然专栏学完了,然而有些内容很快就会忘记,后面我还会偶尔拿出来读一读,回顾一下思路。我现在已经欣然接受,学习的东西很快会遗忘,但回顾的时候会迅速地想起来,印象也更深刻了。

    最后,祝王争老师和编辑小姐姐新年快乐,辛苦了。(´▽`ʃ♡ƪ)
    展开
     1
     67
  • 李
    2019-02-04
    以前觉得数据结构和算法很难,学了之后,确实也难,但通过系统学习,心中有了一张完整的地图,以后只要不断反复看,反复学习,反复练习,一定能真正融合贯通。
    另外,最大的感受是学了数据结构和算法后,看其它中间件和框架的源代码,发现大部分底层就是数据结构和算法。感觉练了九阳神功一样,学习其它功夫快了很多
     1
     16
  • Sharry
    2019-02-11
    问题一:
    - 尝试将用户 自定义后的短网址 和 原网址的映射关系 存入数据库
      - 插入成功, 则提示用户短网址生成成功
      - 若插入失败, 说明存在冲突, 则进行判重处理
         - 若数据库中短网址对应的原网址与当前正在处理的相同, 提示该短网址有效
         - 若数据库中短网址对应的原网址与当前正在处理的不相同, 提示该短网址已被占用

    问题二:
    可以使用布隆过滤器进行判重验证, 通过之后再插入
    展开
     1
     11
  • 微秒
    2019-02-04
    坚持到了最后,虽然只看不写,但也加深了对数据结构的认识,接下来刷第二遍的时候再加深代码实践。最后祝大家新年快乐!顺便说句,老师的这个专栏真的很良心,谢谢了!
    
     11
  • 小美
    2019-02-09
    王老师短网址有什么作用吗? 我上网查了下理由不能说服我?
    可能网上说得比较浅显,王老师方便指导下吗?

    作者回复: 比如微博里,网址如果很长,看起来不美观。缩短成短网址之后,短短的,不占空间,不是更好看些吗:)

     4
     6
  • TryTs
    2019-02-04
    兴趣是最好的老师,这话没有错。如果没有兴趣那就去找。就我个人看法,很多时候一开始不一定非要搞那么枯燥的东西,做一些有趣的东西,慢慢培养自己的兴趣,自己就会有好奇心去往深处学习,如果以来就弄那些很“艰深”的东西,可能不能坚持多久,“从入门到放弃”。学习老师这个专栏,我最大的收获就在于老师把平时课上那些算法讲活了,应用到具体场景之中,相较于一些为了练习而联系的习题,这让我更能体会到算法之美。也在不断激发我的好奇心。我希望自己能够一直抱持这份好奇心。继续努力学习。
    
     6
  • xuery
    2019-04-11
    追到这里,终于有底气在简历上写上一行熟悉各种数据结构与算了^_^.
    感谢王争老师,下一步就是利用leetcode进一步提升自己的算法功底,
    将熟悉变成精通
     1
     4
  • 一涛
    2019-02-04
    1. 首先查询“用户自定义部分”是否与已经生成的短网址冲突,如果冲突,只能提示用户进行修改。如果不冲突,将“用户自定义部分”和对应的原始网址写入数据库即可。

    2. 给原始网址加唯一索引。如果写入异常,说明原始网址已经存在,再根据原始网址查询一次,取出短网址返回给用户。

    不知道回答对不对,请老师指正
    
     4
  • ./+-@YOU
    2019-03-17
    第二题:id生成器,不处理,会导致相同的长域名重复。有个解决方案,长域名设置唯一的限制,在重复的情况下,插入表失败后,查询已经存在的长域名,对应的短域名。返回该短域名
    
     2
  • wahaha
    2019-03-09
    16进制应该是A到F(不是E)表示10到15,文字和朗读中都弄错了
    
     2
  • 李雷
    2019-02-28
    坚持到了最后,给自己个赞
    
     2
  • 失火的夏天
    2020-01-10
    本来想针对思考题二说一点的,结果评论翻到了(*^▽^)/★*☆,数据量大,如果用的传统关系型数据库,就可以采用水平分表,这里好像用不到垂直分表,因为没什么别的无关字段。同时可以考虑分库的情况,通过中间件路由到不同的数据库中。

    不过关系型数据库设计之初对数据预估不完全的话,就算分库分表了,依然会造成单表数据巨大,这个时候再来做数据迁移成本极高,所有数据又要全部重新分库分表。这个时候就轮到NoSQL出场了,因为它天生就支持分库分表,而且扩展性也优秀。
    
     1
  • Jackson
    2020-01-04
    之前没有坚持下来,拖了很久,觉得不应该辜负了自己花的钱还有就是老师的辛苦,所以咬咬牙重新开始从第一讲开始学习,终于学完了,但是我觉得我还会继续看第二遍第三遍的,因为每次学习都会有不一样的知识,都能想到不一样的问题和思路,最后说一句,谢谢老师。
    
     1
  • Swing
    2019-12-23
    em,第一遍 2019.11.27-2009.12.23,买了一年多才来看
    年底辞职准备跳槽,所以工作日看,周末出去玩,断断续续的,也算是过完了,mark下。

    总结下:

    1、感谢 王争 老师,绝大多数的知识点 讲的都很好,剩下一部分感觉没讲清楚,略微遗憾(虽然知道已完结,不太可能了,但还是希望 能有后续的优化);
    但 这是我买了一堆课程和资料后,第一个认真看完的专栏了!!!

    2、整个课程 虽然 本人基本都是在看和思考,没怎么敲代码来落实成果;红黑树、动态规划最后一节 也没搞懂(有点挫败)
    但是 各种字符串匹配算法、AC自动机 也能自己啃下来,也算 增强了不少自信心吧,起码让我这个之前非科班、对算法一无所知、半路入门直接入行的android开发者,
    对算法有了一个系统、整体的认识,也认识到了 原来看来高大上的算法 没有那么遥不可及(嘿嘿,起码普通的算法是);
    至于那些只用零散时间、就能迅速看完并理解的初学者。。。厉害啊!!!

    3、每篇文章后 大家的留言 挺有意思,也有一些启发。。。
    美中不足的是,一些错误的观点 也被放进来了(可能需要 对口专业的人来审核吧)
    展开
    
     1
  • steve
    2019-10-08
    思考题2想了很久没想到好的办法,还请老师解答。
    看大家的方法貌似是把老的url批量删掉,那如果需求不允许失效老url是不是就没有办法了呢?

    作者回复: 分库分表存储啊,或者用一些大型key-value数据库

    
     1
  • 实验室清洁工
    2019-02-13
    应该是16进制吧,62进制???

    作者回复: 是的,62进制会更短些

     2
     1
  • bens
    2019-02-11
    id生成器用snowflake算法解决
    
     1
  • 纯洁的憎恶
    2019-02-07
    1.短网址的自定义部分是要展示给用户的。是否可以把自定义部分作为第三个字段存入数据库。如果不同用户对相同原网址申请短网址自定义部分不同。要么不允许这种行为,否则就得把自定义部分与原网址拼接输入哈希函数,以实现区分。
    
     1
  • 纯洁的憎恶
    2019-02-07
    通过哈希函数,在长网址字符串基础上,生成短网址哈希值。将哈希值从10进制提升至62进制,进一步缩短短网址长度。为了通过短网址回溯到原网址,需要建立长短网址的对应关系,存入数据库。

    为了避免散列冲突,需要在在建立新的对应关系时,查询数据库中是否已有短网址,若有再检查长网址是否一致,若不一致则发生冲突,需要给新的长网址字符串加前缀,再用哈希函数生成短网址,直到没有冲突,最终将前缀、对应关系均存入数据库。

    为方便查询,需要在数据库中建立短网址的索引(B+树)。减少SQL语句数量也可以提高性能,把查询+写入两条语句,简化为写入一条。代价是设置短网址唯一索引,不允许出现重复,这样当重复写入时数据库才会报错,此时再通过查询、前缀、写入的方式解决散列冲突。也可以针对短网址建立布隆过滤器,当新的短网址不在过滤器中则正常写入,否则通过查询判重并解决冲突。

    另一种方式是通过全局计数器,给每个请求的原网址分配一个序号,作为短网址的主要部分。但它可能造成同一个原网址对应多个短网址的现象(虽然不影响应用体验)。为提高给号的并发性能,可以针对不同号段设置多个发号器并行发号。
    展开
    
     1
  • 与非
    2019-02-04
    最后一课在一年的最后一天结束,这也算辞旧迎新了吧~希望老师能在最后能出个课后思考题的总结~
    
     1
我们在线,来聊聊吧