科技新闻

【巨杉数据库SequoiaDB】巨杉Tech | “删库跑路”又出现,如何防范数据安全风险?

元气小坏坏 提交于 2020-02-28 17:01:41
最近,又双叕有企业被“删库”了。来自微盟官网的消息,微盟的业务系统数据库(包括主备)遭遇其公司运维人员的删除,系统将停止运营超48小时。 频发的类似事件也让大家对于数据安全的关注不断提高。数据是一个科技企业的核心资产,删库事件频发其实也是在提醒大家对于数据安全必须重视。想要预防风险,既需要企业建立完善的数据权限管理制度,也需要企业注重数据备份和容灾等架构的搭建。 权限管理,可以区分为角色管理和层级管理方式。角色管理就是区分应用运维、系统运维、DBA 等多类岗位角色,每个岗位都只能接触自己所负责业务的数据,以及相应可执行的权限。层级管理,则是垂直向的细化分级,将各个员工层级可以进行的操作进行严格的区分和限制,并且严格遵守审批审核的制度,避免因为省事而将重要权限放松管理。 防灾预案,演练和预案是十分容易被技术团队忽略的一个重要风险因素。就像是政府,无论是应对疫情还是突发事件,都会有一套完善的应急预案和响应机制,在事情发生时最快反应,及时止损,尽快恢复。 备份容灾,对于大型企业,数据的备份、容灾是必不可少的。以金融行业举例,在中国,对于大部分银行数据中心,监管机构目前提出了对于数据安全和数据高可用的“两地三中心”以及“双活”的能力。“两地三中心”即生产数据中心、同城灾备中心和异地灾备中心建设方案。这种模式下,两个城市的三个数据中心互联互通,如果一个数据中心发生故障或灾难

【巨杉数据库SequoiaDB】巨杉Tech | “删库跑路”又出现,如何防范数据安全风险?

拜拜、爱过 提交于 2020-02-28 16:55:34
最近,又双叕有企业被“删库”了。来自微盟官网的消息,微盟的业务系统数据库(包括主备)遭遇其公司运维人员的删除,系统将停止运营超48小时。 频发的类似事件也让大家对于数据安全的关注不断提高。数据是一个科技企业的核心资产,删库事件频发其实也是在提醒大家对于数据安全必须重视。想要预防风险,既需要企业建立完善的数据权限管理制度,也需要企业注重数据备份和容灾等架构的搭建。 权限管理 ,可以区分为 角色管理 和 层级管理 方式。 角色管理 就是区分应用运维、系统运维、DBA 等多类岗位角色,每个岗位都只能接触自己所负责业务的数据,以及相应可执行的权限。 层级管理 ,则是垂直向的细化分级,将各个员工层级可以进行的操作进行严格的区分和限制,并且严格遵守审批审核的制度,避免因为省事而将重要权限放松管理。 防灾预案 ,演练和预案是十分容易被技术团队忽略的一个重要风险因素。就像是政府,无论是应对疫情还是突发事件,都会有一套完善的应急预案和响应机制,在事情发生时最快反应,及时止损,尽快恢复。 备份容灾 ,对于大型企业,数据的备份、容灾是必不可少的。以金融行业举例,在中国,对于大部分银行数据中心,监管机构目前提出了对于数据安全和数据高可用的“两地三中心”以及“双活”的能力。“两地三中心”即生产数据中心、同城灾备中心和异地灾备中心建设方案。这种模式下,两个城市的三个数据中心互联互通

5分钟带你体验一把 Kafka

余生颓废 提交于 2020-02-28 16:10:10
说在文章前面的话: 前置条件:你的电脑已经安装 Docker 主要内容: 使用 Docker 安装 使用命令行测试消息队列的功能 zookeeper和kafka可视化管理工具 Java 程序中简单使用Kafka 使用 Docker 安装搭建Kafka环境 单机版 下面使用的单机版的Kafka 来作为演示,推荐先搭建单机版的Kafka来学习。 以下使用 Docker 搭建Kafka基本环境来自开源项目:github.com/simplesteph… 。当然,你也可以按照官方提供的来:github.com/wurstmeiste… 。 新建一个名为 zk-single-kafka-single.yml 的文件,文件内容如下: version: '2.1' services: zoo1: image: zookeeper:3.4.9 hostname: zoo1 ports: - "2181:2181" environment: ZOO_MY_ID: 1 ZOO_PORT: 2181 ZOO_SERVERS: server.1=zoo1:2888:3888 volumes: - ./zk-single-kafka-single/zoo1/data:/data - ./zk-single-kafka-single/zoo1/datalog:/datalog kafka1: image:

Kafka设计解析(四):Kafka Consumer解析

送分小仙女□ 提交于 2020-02-28 16:00:22
High Level Consumer 很多时候,客户程序只是希望从Kafka读取数据,不太关心消息offset的处理。同时也希望提供一些语义,例如同一条消息只被某一个Consumer消费(单播)或被所有Consumer消费(广播)。因此,Kafka High Level Consumer提供了一个从Kafka消费数据的高层抽象,从而屏蔽掉其中的细节并提供丰富的语义。 Consumer Group High Level Consumer将从某个Partition读取的最后一条消息的offset存于ZooKeeper中( Kafka从0.8.2版本 开始同时支持将offset存于Zookeeper中与 将offset存于专用的Kafka Topic中 )。这个offset基于客户程序提供给Kafka的名字来保存,这个名字被称为Consumer Group。Consumer Group是整个Kafka集群全局的,而非某个Topic的。每一个High Level Consumer实例都属于一个Consumer Group,若不指定则属于默认的Group。ZooKeeper中Consumer相关节点如下图所示: 很多传统的Message Queue都会在消息被消费完后将消息删除,一方面避免重复消费,另一方面可以保证Queue的长度比较短,提高效率。而如上文所述

RabbitMQ入门

被刻印的时光 ゝ 提交于 2020-02-28 15:27:39
文章目录 RabbitMQ简介 各大主流中间件对比 初识RabbitMQ RabbitMQ高性能的原因 什么是AMQP高级消息队列协议 AMQP核心概念(重点) RabbitMQ安装及使用 Centos安装方式 RabbitMQ安装与使用 Docker安装方式 常用操作命令 RabbitMQ快速入门 交换机 直流交换机 主题交换机 输出交换机 RabbitMQ简介 各大主流中间件对比 ActiveMQ ActiveMQ 是 Apache 出品,最流行的,能力强劲的开源消息总线,并且它一 个完全支持 J M S 规范的消息中间件。 其丰富的 API 、多种集群构建模式使得他成为业界老牌消息中间件,在中 小型企业中应用广泛! MQ 衡量指标:服务性能、数据存储、集群架构 Kafka Kafka用来做日志分析 RocketMQ RocketMQ是阿里开源的消息中间件,目前也已经孵化为Apache顶级项目, 它是纯java开发,具有高吞吐量、高可用性、适合大规模分布式系统 应用的特点。 RocketMQ思路起源于Kafka,它对消息的可靠传输及事务 性做了优化, 目前在阿里集团被广泛应用于交易、充值、流计算、消息推 送、日志流式处理、binglog分发等场景 RabbitMQ RabbitMQ是使用Erlang语言开发的开源消息队列系统,基于AMQP协议 来实现。

vim相关字符集设置

本秂侑毒 提交于 2020-02-28 15:21:25
fileencoding:Vim中当前编辑的文件的字符编码方式,Vim保存文件时也会将文件保存为这种字符编码方式 (不管是否新文件都如此)。 fileencodings:Vim启动时会按照它所列出的字符编码方式逐一探测即将打开的文件的字符编码方式,并且将fileencoding设置为最终探测到的字符编码方式。 encoding:Vim内部使用的字符编码方式,包括Vim的buffer(缓冲区)、菜单文本、消息文本等。 termencoding:如果在终端环境下使用Vim,需要设置termencoding和终端所使用的编码一致。 来源: CSDN 作者: 陈正跃 链接: https://blog.csdn.net/weixin_39366864/article/details/104552138

MQ技术

二次信任 提交于 2020-02-28 14:53:08
MQ技术(消息队列) 消息中间件概述 消息队列技术是分布式应用间交换信息的一种技术。 消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。 通过消息队列,应用程序可独立地执行–它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。 消息队列为构造以同步或异步方式实现的分布式应用提供了松耦合方法。 消息队列的API调用被嵌入到新的或现存的应用中,通过消息发送到内存或基于磁盘的队列或从它读出而提供信息交换。 消息队列可用在应用中以执行多种功能,比如要求服务、交换信息或异步处理等。 消息队列的四大好处: 1.解耦:每个成员不必受其他成员影响,可以更独立自主,只通过一个简单的容器来联系。 2.提速 3.广播 4.削峰 消息队列的成本: 1.引入复杂度 2.暂时的不一致性 中间件是一种独立的系统软件或服务程序,分布式应用系统借助这种软件在不同的技术之间共享资源,管理计算资源和网络通讯。 它在计算机系统中是一个关键软件,它能实现应用的互连和互操作性,能保证系统的安全、可靠、高效的运行。 中间件位于用户应用和操作系统及网络软件之间,它为应用提供了公用的通信手段,并且独立于网络和操作系统。 中间件为开发者提供了公用于所有环境的应用程序接口,当应用程序中嵌入其函数调用,它便可利用其运行的特定操作系统和网络环境的功能,为应用执行通信功能。 如果没有消息中间件完成信息交换

ID生成器之——别人家的方案and自家的方案

你离开我真会死。 提交于 2020-02-28 14:50:23
“叮咚,叮咚……”,微信提示音一声接一声,声音是那么的频繁,有妖气,待俺去看一看。 这天刚吃完午饭,打开微信,发现我们的技术讨论组里有 100 多条未读消息,心想,是不是系统出问题了?怎么消息那么频繁? 于是迅速的爬楼,历时 1 秒 23,爬到楼顶,虚惊一场。了解消息的来龙去脉,大体意思:下午两点,研发一组在第二会议室开会,会议主题是:开发一个适合多个业务场景的分布式 ID 生成器。 到了两点,我们都来到第二会议室,开始了激烈讨论。 可能你们都知道,ID 是某个体系中唯一的编码,用来标识事务,比如:身份标识号、账号、唯一编码、专属号码。 ID 生成器又是什么呢?说白了就是生成 ID 工具,而在这里我们说的 ID 生成器,是一个服务(下同)。 为什么要开发分布式 ID 生成器? 原因大体有两点: 1. 许多业务系统需要对大量的订单、消息进行进行唯一标识,如:金融、电商、支付等。 2. 每个部门都开发一套 ID 生成器,总体上增加了工作量,增加公司的成本,不利于维护、管理。 分布式 ID 生成器有哪些要求? 1. 全局唯一性:不能出现重复的 ID 号,既然是唯一标识,这是最基本的要求。 2. 递增:比较低要求的条件为趋势递增,即保证下一个 ID 一定大于上一个 ID,而比较苛刻的要求是连续递增,如1001,1002,1003 等等。根据我们自己的业务,我们选择的是趋势递增(连续递增

Java网络编程之UDP程序设计

空扰寡人 提交于 2020-02-28 13:58:02
1.UDP简介 使用UDP发送消息,对方不一定收到,因为所有的信息使用数据报的形式发送出去,这就要求客户端要始终等待接收服务器发送过来的信息,在Java中使用DatagramSocket类和DatagramPacket类完成UDP程序的开发。 2.程序实现 使用DatagramPacket类包装一条要发送的信息,之后使用DatagramSocket类用于完成信息的发送操作。DatagramPacket类的常用方法: 类型 方法 描述 构造 DatagramPacke t(byte[] buf, int length) 构造 DatagramPacket ,用来接收长度为 length 的数据包。 构造 DatagramPacket (byte[] buf, int length, InetAddress address, int port) 构造数据报包,用来将长度为 length 的包发送到指定主机上的指定端口号。 byte[] getData () 返回数据缓冲区。 int getLength () 返回将要发送或接收到的数据的长度。 DatagramSocket类常用方法: 类型 方法 描述 构造 DatagramSocket (int port) 创建数据报套接字并将其绑定到本地主机上的指定端口。 void send (DatagramPacket p)

ActiveMQ的安装与配置详情

爷,独闯天下 提交于 2020-02-28 13:39:10
(1)ActiveMQ的简介 MQ: (message queue) ,消息队列,也就是用来处理消息的,(处理JMS的)。主要用于大型企业内部或与企业之间的传递数据信息。 ActiveMQ 是Apache出品,最流行的,能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现,尽管JMS规范出台已经是很久的事情,但是JMS在当今的J2EE应用中间仍然扮演着特殊的地位。JMS 即Java消息服务(Java Message Service)应用程序接口是一个Java平台中关于面向消息中间件(MOM)的API,用于在两个应用程序之间,或分布式系统中发送消息,进行异步通信。Java消息服务是一个与具体平台无关的API,绝大多数MOM(manager of managers)提供商都对JMS提供支持。 消息的主要模型有两种:PTP和PUB/SUB,即点对点(一对一)和发布订阅模式(一对多) P2P的特点:  三个重点:队列(queue) 生产者(sender) 消费者(receiver) 每个消息都被发送到一个特定的队列,接收者从队列中获取消息。队列保留着消息,直到他们被消费或超时。 每个消息只有一个消费者(Consumer)(即一旦被消费,消息就不再在消息队列中) 发送者和接收者之间在时间上没有依赖性,当发送者发送了消息之后