Protogalaxy

Planet #0

英雄联盟电竞赛事直播指南

前段时间在dc的服务器比赛里承担了几次直播员的任务,作为技术栈的一部分,把直播中用到的技术和要点整理成文章记录在了Github上,为了存档,在这里也保存一份,Github链接:https://github.com/SolitudeRA/LOL-eSports-Streaming-Handbook 英雄联盟电竞直播手册(不含国服) In-game观赛UI设计数据 观赛UI Layout 直播工具链 OBS OBS Studio是一款开源的直播工具,可以帮助你快速的开始直播,并且可以帮助你快速的推送直播内容。 下载地址 League prod toolkit 用于英雄联盟电竞直播的开源OBS浮层工具,提供赛前BP,游戏内事件,赛后面板等功能。 Github页面 League observer tool League prod toolkit的本地OB工具,用于与League prod toolkit的LCU端点进行通信,提供游戏内事件监测。 Github页面 Creator Suite Replay / League DirectorContinue reading英雄联盟电竞赛事直播指南

PHSS-Core开发日志#10 FFmpeg与其JavaCPP实现踩坑纪录

Ps.PHSS的这部分开发过程中还衍生出了一个基于FFmpeg的java原生音视频metadata获取的轮子,相关文章可以参考这里。 前言 在完成了简单的安全层架构,实现了基本的登录功能之后,项目中于是进入了较为核心的音视频管理功能的开发阶段,在前期技术选型时,考虑到项目的可维护性与稳定性,我最终选择了FFmpeg作为PHSS的多媒体管理外部库,作为老牌多媒体处理软件,FFmpeg的可用性与稳定性都是经过了多年生产环境检验的。 但是在编写专辑音轨管理功能的具体实现过程中,我发现FFmpeg这个东西竟然找不太到全面且易读的开发相关的Guide和Documentation。并且实际使用过程中所用到的FFmpeg的Java实现(FFmpeg-JavaCPP-Presents,基于JavaCPP,由Bytedeco编写)更是只有一个基本的demo,FFmpeg的其他更深度的内容也是一点都没提,在Google上能找到的也大多都是命令行版的FFmpeg的使用方法,在Github上能找到的音视频metadata获取相关的项目也大多都是基于命令行版FFmpeg或者是其他一些奇奇怪怪的,早已停止更新的第三方库,看起来非常的不靠谱。由于FFmpeg的Java实现是基于JavaCV的子项目,更新一直都非常稳定,所以我还是坚定不移的选择了JavaCPP版FFmpeg作为项目的多媒体处理库,因此我只能自己一点点看那个JavaDoc和网上能找到的一些零星的老版本的开发示例来一点点学习相关的开发知识,在这里记录以下,方便自己和其他有需要的老哥们日后有个参考。(以下叙述是以FFmpeg-JavaCPP作为基础,其基础技术JNI的相关介绍可以点这里)

PHSS-Core开发日志#6 密码加密算法对比

在互联网发展的初期,密码大多是以明文存储的,因为密码被认为是安全的,它需要凭证才能够被访问到。但是,攻击者可以通过SQL注入等攻击方式来获取大量的密码。随着越来越多的密码被这些攻击手段所获取,安全领域的专家们开始意识到需要一中更加安全的方式来保护用户的密码。 随后,安全领域开始鼓励开发人员使用单向散列算法(也称Hash算法,例如SHA256)来将密码进行加密存储。当用户尝试认证时,系统将用户上传的密码hash后与数据库中储存的hash值进行比较,这意味着数据库只需存储密码的单向散列。如果系统被攻破,也只会暴露密码的单向散列,由于在计算上很难通过单向散列值来破解密码,因此这种方法在很大程度上提高了密码的安全性。但是随着黑客技术的发展,攻击者也开始使用彩虹表(Rainbow Tables)来辅助破解,攻击者并不是每次都是在猜测密码,而是通过彩虹表来使用“以空间换时间”的策略来进行密码破解。

数据库设计与性能优化笔记整理

数据库设计范式: 总的设计思路大致为:消除数据冗余,避免插入/删除/修改异常 相关名词解释: 码:关系中的某个属性或某几个属性的组合,用于区分数据库中每条记录 函数性依赖:在一张表中,在属性/属性组中的X值确定的情况下,必能确定属性Y的值,这里的函数不是一种特定的数字关系,而是一种抽象的关系概念,比如学号→姓名。 传递函数依赖:有传递性的依赖关系,例如A→B,B→C,则C与A具有传递函数依赖关系。 1NF:即表中的所有属性都不可再分割,1NF为所有关系型数据库的基本要求。 2NF:在1NF的基础上,消除非主属性对于码的部分函数性依赖。 3NF:在2NF的基础上,消除非主属性对于码的传递函数依赖。 范式的优点与缺点: 范式的更新操作通常比反范式要快。 当数据较好的范式化时,就只有很少甚至没有冗余数据,所以修改所带来的开销会相对较少。 范式化的表通常体积较小,可以更好地放在内存中,所以执行操作会更快。 冗余数据较少意味着在查询检索时会更少需要DISTINCT或者GROUP BY语句。 范式化设计的schema的缺点是通常需要关联。稍微复杂一些的查询语句在符合范式的schema上可能需要至少一次甚至更多关联。这不但代价昂贵,也可能使一些索引策略失效。例如,范式化可能将列存放在不同的表中,而这些列如果在一个表中本可以属于同一个索引。 反范式的优点与缺点: 反范式化的schema因为所有的数据都在一张表中,所以可以很好的避免关联。 如果不需要关联表,则对大部分查询最差的情况–即使表没有使用索引–是全表扫描。当数据比内存大时这可能比关联要快得多,因为这样避免了随机I/O。 关于使用自增主键与使用UUID作为主键的主键策略对比(InnoDB): 首先介绍InnoDB的主键索引方式-聚簇索引:聚簇索引定义了表中数据的物理存储顺序,相邻主键的物理位置也是相邻的,按照大小排序。由于·UUID为无序数列,所以在索引时会降低索引性能,造成巨大的IO压力。 存储空间方面:UUID由于长度的关系,在数据量上升时会造成一定的存储压力 数据独立性方面:自增主键在合并表的时候可能会出现主键重复的情况,而UUID不仅是表独立的,而且是库独立的,在数据库切分与合并时比较方便 分布式存储:由于UUID的独立性,相比自增主键而言更适合与分布式存储 关于twitter开源分布式自增ID算法snowflake: Github:https://github.com/twitter/snowflake   部分内容摘自《高性能MySQL》,在这里也向想了解更多关于数据库设计优化的小伙伴推荐这本书,写的还挺不错的。